From nobody Fri Dec 4 10:57:43 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D728C3A0EAD for ; Fri, 4 Dec 2020 10:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FC529xGZ3SyN for ; Fri, 4 Dec 2020 10:57:40 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3333A0B2D for ; Fri, 4 Dec 2020 10:57:40 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id d9so6406253qke.8 for ; Fri, 04 Dec 2020 10:57:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=lBHqcCCUNsgbHNczUWUQbnBLRiMQqn/t8UBcfVIlEkg=; b=dFgmTpv8E8LgKOjsLaZ+qoSDLunahEfycLvmu2LsrKNoJxPOVBT1KnKlkQw0+cnosg C+0I0vk3WrVvPquql0FRH3bCRp7ifmtNvLOsLG4JCt9L+tDnilaYjlBgd+VYdQ5KpYDy na5bjCXQCANJi44Svaw8WjSXTQrncQbJjbIFZZv+adbmmkUP3O0Q5LNX/qPq+v2FosHV 3Oa7TDufsQR1sMsGveEvNrP31deQMTP4cXqoIJkpRyMnDfdJunGoFpOfR3H5GWGR8in9 s8AouGsHdizz/AKzZfKI/wqQMVyKySGkbErVKGHvpSBqP903P4RrjoDChZ4a32LZUUrO OVzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=lBHqcCCUNsgbHNczUWUQbnBLRiMQqn/t8UBcfVIlEkg=; b=WYyHZlx0yCyp+BqjaA0O59M14MybBYza8qalDQLS4OYfpCpNZjAZWflc1gvFP5YD8H F8phivm16MLSjAClud0lArwmomdn+iBhD8JnUCAkBv0WjuQcmm9X8/PCzCLRHj6LmV6z 30LkREy5BPixIBGxmCwbKHuHVwabM1ZqN5IgESfRf2MheGhffCM3Lz1Se0oMeNGABf3G samue7jKR3pcKQGWpvqnvC1Mweum9HvgT49PB88iMKM17lrPlRZESCZv5JuTfQC3jskl G9vrdqJvASjMvhA2L1HRRco2M84uq/0PPwoDxbxJLRzDaxtB0vl60tAkWZh8BAbwMxm9 Fslg== X-Gm-Message-State: AOAM531cusIo4Ghl7t/Di0FunouL6+owxpcxuPm4qxGbU5KSAnBSwVJO prS+O5tvCY28XaBWSS4IlujnMfmY9UQI+3Ps X-Google-Smtp-Source: ABdhPJxfPaktWLf4RqpBl1tN1LVIUU2oFA7HnPPJjFDsZWitXni+7fxEH/dUB+z7BCvwoTR8Todw3Q== X-Received: by 2002:a37:a2cb:: with SMTP id l194mr9985417qke.319.1607108259188; Fri, 04 Dec 2020 10:57:39 -0800 (PST) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id u72sm6310819qka.15.2020.12.04.10.57.38 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2020 10:57:38 -0800 (PST) From: Brian Rosen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <7B667092-50A3-42AC-80AD-CBC6FDD51FC0@brianrosen.net> Date: Fri, 4 Dec 2020 13:57:37 -0500 To: ECRIT X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [Ecrit] A few issues with RFC7852 (Additional Data) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 18:57:42 -0000 In a discussion in NENA, a few issues were discovered with the = Additional Data document. 1. The purpose parameter contains the type of block. What happens if the = actual block type received is not what the purpose parameter says? If we do a bis of this document, we might want to state why the block = type is part of the purpose parameter: it=E2=80=99s because if the block = is passed by reference, you want to know, before you dereference the = URL, what kind of block it is. This error (block type not the same as = purpose) isn=E2=80=99t anything we can really do anything about. But at = least we should say something about the possibility and consequences. 2. How long does the reference work after the Additional Data reference = is passed? In NENA docs we say =E2=80=9Ca few minutes past the end of = the emergency call=E2=80=9D. That=E2=80=99s probably not good enough = for Additional Data: it has to be valid for the entire incident the call = references. The calling device/service provider doesn=E2=80=99t know = that, so we probably have to have a time based recommendation that is = measured in hours. Brian From nobody Sun Dec 6 12:17:07 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933663A0B37 for ; Sun, 6 Dec 2020 12:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_RELAY_MUA_TO_MX=3.653, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgp8raLEqTF4 for ; Sun, 6 Dec 2020 12:17:05 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id EDBBE3A0B35 for ; Sun, 6 Dec 2020 12:17:04 -0800 (PST) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 6 Dec 2020 12:17:31 -0800 From: "Randall Gellens" To: "Brian Rosen" Cc: ECRIT Date: Sun, 06 Dec 2020 12:17:03 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: <020A743E-748C-4319-AE64-183149B2BF06@randy.pensive.org> In-Reply-To: <7B667092-50A3-42AC-80AD-CBC6FDD51FC0@brianrosen.net> References: <7B667092-50A3-42AC-80AD-CBC6FDD51FC0@brianrosen.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_BE6AE1EC-B6CD-4017-B644-79F54DE94674_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ecrit] A few issues with RFC7852 (Additional Data) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2020 20:17:07 -0000 --=_MailMate_BE6AE1EC-B6CD-4017-B644-79F54DE94674_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit More generally, the reason the block type MUST be a registered emergency call additional data block and the block type is part of the Call-Info 'purpose' parameter is so an entity can determine using rules if it will access the block or not. This applies regardless of the block is passed by reference or by value. The expectation is that, for example, PSAPs will determine the handling of various types of data using a set of rules, (not unlike policy routing), e.g., specifying which data elements of which blocks are displayed to a call taker on call presentation vs available to a call taker by request vs not accessed. RFC 7852 Section 6 does mention the possibility of having a different block type than what the 'purpose' parameter indicated: Note that, as with any mechanism, failures are possible. For example, a block (provided by value or by reference) might not be the type indicated by the 'purpose' parameter, or might be badly formed, etc. The general principle that applies to emergency calls is that it is more important for the call to go through than for everything to be correct. Thus, most PSAPs will process a call if at all possible, even if data is missing or other failures occur. --Randall On 4 Dec 2020, at 10:57, Brian Rosen wrote: > In a discussion in NENA, a few issues were discovered with the > Additional Data document. > > 1. The purpose parameter contains the type of block. What happens if > the actual block type received is not what the purpose parameter says? > If we do a bis of this document, we might want to state why the block > type is part of the purpose parameter: it’s because if the block is > passed by reference, you want to know, before you dereference the URL, > what kind of block it is. This error (block type not the same as > purpose) isn’t anything we can really do anything about. But at > least we should say something about the possibility and consequences. > > 2. How long does the reference work after the Additional Data > reference is passed? In NENA docs we say “a few minutes past the > end of the emergency call”. That’s probably not good enough for > Additional Data: it has to be valid for the entire incident the call > references. The calling device/service provider doesn’t know that, > so we probably have to have a time based recommendation that is > measured in hours. > > Brian > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_MailMate_BE6AE1EC-B6CD-4017-B644-79F54DE94674_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

More generally, the reason the block type MUST be a regis= tered emergency call additional data block and the block type is part of = the Call-Info 'purpose' parameter is so an entity can determine using rul= es if it will access the block or not. This applies regardless of the bl= ock is passed by reference or by value. The expectation is that, for exa= mple, PSAPs will determine the handling of various types of data using a = set of rules, (not unlike policy routing), e.g., specifying which data el= ements of which blocks are displayed to a call taker on call presentation= vs available to a call taker by request vs not accessed.

RFC 7852 Section 6 does mention the possibility of having= a different block type than what the 'purpose' parameter indicated:

Note that, as wit=
h any mechanism, failures are possible.  For
example, a block (provided by value or by reference) might not be the
type indicated by the 'purpose' parameter, or might be badly formed,
etc.  The general principle that applies to emergency calls is that
it is more important for the call to go through than for everything
to be correct.  Thus, most PSAPs will process a call if at all
possible, even if data is missing or other failures occur.

--Randall

On 4 Dec 2020, at 10:57, Brian Rosen wrote:

I= n a discussion in NENA, a few issues were discovered with the Additional = Data document.

1. The purpose parameter contains the type of block. What happens if the = actual block type received is not what the purpose parameter says?
If we do a bis of this document, we might want to state why the block typ= e is part of the purpose parameter: it=E2=80=99s because if the block is = passed by reference, you want to know, before you dereference the URL, wh= at kind of block it is. This error (block type not the same as purpose) = isn=E2=80=99t anything we can really do anything about. But at least we = should say something about the possibility and consequences.

2. How long does the reference work after the Additional Data reference i= s passed? In NENA docs we say =E2=80=9Ca few minutes past the end of the= emergency call=E2=80=9D. That=E2=80=99s probably not good enough for Ad= ditional Data: it has to be valid for the entire incident the call refere= nces. The calling device/service provider doesn=E2=80=99t know that, so = we probably have to have a time based recommendation that is measured in = hours.

Brian

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--=_MailMate_BE6AE1EC-B6CD-4017-B644-79F54DE94674_=-- From nobody Sat Dec 19 11:49:15 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6723A0EC3 for ; Sat, 19 Dec 2020 11:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwNhkqX5Zhox for ; Sat, 19 Dec 2020 11:49:12 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936BA3A0EC1 for ; Sat, 19 Dec 2020 11:49:12 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 7F89DF4074D; Sat, 19 Dec 2020 11:48:59 -0800 (PST) To: hgs+ecrit@cs.columbia.edu, superuser@gmail.com, barryleiba@computer.org, allison.mankin@gmail.com, roger.marshall@comtechtel.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: worley@ariadne.com, ecrit@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20201219194859.7F89DF4074D@rfc-editor.org> Date: Sat, 19 Dec 2020 11:48:59 -0800 (PST) Archived-At: Subject: [Ecrit] [Editorial Errata Reported] RFC5031 (6359) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2020 19:49:14 -0000 The following errata report has been submitted for RFC5031, "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6359 -------------------------------------- Type: Editorial Reported by: Dale R. Worley Section: 4.2, 7.2 Original Text ------------- In section 4.2: The 'sos' service type describes emergency services requiring an immediate response, typically offered by various branches of the government or other public institutions. Corrected Text -------------- In section 4.2, add a reference: The 'sos' service type describes emergency services requiring an immediate response, typically offered by various branches of the government or other public institutions. [IRC] In section 7.2, add a reference: [IRC] Service Regulations annexed to the International Radiotelegraphic Convention, Berlin, 1906, section 6. a., article XVI. https://babel.hathitrust.org/cgi/pt?id=hvd.32044103239133&view=1up&seq=36 Notes ----- The referenced section of the protocols of the convention is "Ships in distress make use of the following signal: . . . - - - . . . repeated at short intervals. ...". Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5031 (draft-ietf-ecrit-service-urn-07) -------------------------------------- Title : A Uniform Resource Name (URN) for Emergency and Other Well-Known Services Publication Date : January 2008 Author(s) : H. Schulzrinne Category : PROPOSED STANDARD Source : Emergency Context Resolution with Internet Technologies RAI Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Sat Dec 19 12:43:57 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8107F3A0F0F for ; Sat, 19 Dec 2020 12:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKBO9pGnUIyx for ; Sat, 19 Dec 2020 12:43:53 -0800 (PST) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EFE93A0F0A for ; Sat, 19 Dec 2020 12:43:53 -0800 (PST) Received: by mail-lf1-f53.google.com with SMTP id h205so14401370lfd.5 for ; Sat, 19 Dec 2020 12:43:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E0YgvKOaOA9Sv9LwtWet4fSODkbJuTVITgGxfFoY/LM=; b=cNa2HJzrmMshwK30/uiM9SZESoc7MurPg3vihGdhYZsXLy8OD5mR7rQ0UFJdxzIH6N 8P6BYCHMk5G926WOn0YIqrjJug9qfQJbvytGeGkAcTMkL+vnmCWQAMLpJEAkg2MMVGzr MMYK6LMyeQHbBuOn93PAwqlTaHejzH6E8UfxFIDIJ/wL4MY3+W0UhVv49niehKtFLNY6 p5NFDcyGH6c/QXFZT/UoLnVsicc9kPUE9fPOs62I+MKZJgQvlPDF/twKlLvisjaYJGN1 zwENAjuiNAjSHYbm8KRJCKjHfv80UCT3BuxHGrfQ6z4UWD6+DYh6p5nsy567d1MkucdK OtLQ== X-Gm-Message-State: AOAM531kSF4aWHrYMHNhuWitHU2SAFMx+za593+1gVmnR6chJPJHXl+5 rCsXG8IB8OTJpB6CHxTnZiRZ0JJbUyTeb079eMw= X-Google-Smtp-Source: ABdhPJy+pmpXERnNeaqqLkw3x11GEHHJB5x01wKAGZ+UIV3IfFAuOXry30RDFtLBUyvFlCdEnSkwV7ws549orEURWmE= X-Received: by 2002:ac2:454e:: with SMTP id j14mr3848758lfm.123.1608410631587; Sat, 19 Dec 2020 12:43:51 -0800 (PST) MIME-Version: 1.0 References: <20201219194859.7F89DF4074D@rfc-editor.org> In-Reply-To: <20201219194859.7F89DF4074D@rfc-editor.org> From: Barry Leiba Date: Sat, 19 Dec 2020 15:43:40 -0500 Message-ID: To: RFC Errata System Cc: allison.mankin@gmail.com, ecrit@ietf.org, hgs+ecrit@cs.columbia.edu, roger.marshall@comtechtel.com, superuser@gmail.com, worley@ariadne.com Content-Type: multipart/alternative; boundary="000000000000594b1005b6d748eb" Archived-At: Subject: Re: [Ecrit] [Editorial Errata Reported] RFC5031 (6359) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2020 20:43:56 -0000 --000000000000594b1005b6d748eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Dale, and thanks for taking the time to file this. I=E2=80=99m quite sure this isn=E2=80=99t really =E2=80=9Cerrata=E2=80=9D, = though, in that there was never an intent to include a reference that explains the background of why it=E2= =80=99s called =E2=80=9Csos=E2=80=9D. And while the reference might be good for am= usement, it doesn=E2=80=99t relate to this usage... the RFC itself explains everything necessary, and the only thing the reference adds is a pointer to why it=E2= =80=99s called =E2=80=9Csos=E2=80=9D. So unless the working group (which is CCed here) thinks it=E2=80=99s worth = making this =E2=80=9CHeld For Document Update=E2=80=9D, I=E2=80=99m inclined to ma= rk it =E2=80=9CRejected=E2=80=9D. Anyone ecrit working group denizens care to comment? Barry On Sat, Dec 19, 2020 at 2:49 PM RFC Errata System wrote: > The following errata report has been submitted for RFC5031, > "A Uniform Resource Name (URN) for Emergency and Other Well-Known > Services". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6359 > > -------------------------------------- > Type: Editorial > Reported by: Dale R. Worley > > Section: 4.2, 7.2 > > Original Text > ------------- > In section 4.2: > > The 'sos' service type describes emergency services requiring an > immediate response, typically offered by various branches of the > government or other public institutions. > > Corrected Text > -------------- > In section 4.2, add a reference: > > The 'sos' service type describes emergency services requiring an > immediate response, typically offered by various branches of the > government or other public institutions. [IRC] > > In section 7.2, add a reference: > > [IRC] Service Regulations annexed to the International Radiotelegraphic > Convention, Berlin, 1906, section 6. a., article XVI. > https://babel.hathitrust.org/cgi/pt?id=3Dhvd.32044103239133&view=3D1up&se= q=3D36 > > > Notes > ----- > The referenced section of the protocols of the convention is "Ships in > distress make use of the following signal: . . . - - - . . . repeated at > short intervals. ...". > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5031 (draft-ietf-ecrit-service-urn-07) > -------------------------------------- > Title : A Uniform Resource Name (URN) for Emergency and > Other Well-Known Services > Publication Date : January 2008 > Author(s) : H. Schulzrinne > Category : PROPOSED STANDARD > Source : Emergency Context Resolution with Internet > Technologies RAI > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > --000000000000594b1005b6d748eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Dale, and thanks for taking the time to file this.

I=E2=80=99m quite sure thi= s isn=E2=80=99t really =E2=80=9Cerrata=E2=80=9D, though, in that there was = never an intent to include a reference that explains the background of why = it=E2=80=99s called =E2=80=9Csos=E2=80=9D.=C2=A0 And while the reference mi= ght be good for amusement, it doesn=E2=80=99t relate to this usage... the R= FC itself explains everything necessary, and the only thing the reference a= dds is a pointer to why it=E2=80=99s called =E2=80=9Csos=E2=80=9D.

So unless the working group (whi= ch is CCed here) thinks it=E2=80=99s worth making this =E2=80=9CHeld For Do= cument Update=E2=80=9D, I=E2=80=99m inclined to mark it =E2=80=9CRejected= =E2=80=9D.=C2=A0 Anyone ecrit working group denizens care to comment?
=

Barry

On Sat, Dec 19, 202= 0 at 2:49 PM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The= following errata report has been submitted for RFC5031,
"A Uniform Resource Name (URN) for Emergency and Other Well-Known Serv= ices".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6359

--------------------------------------
Type: Editorial
Reported by: Dale R. Worley <worley@ariadne.com>

Section: 4.2, 7.2

Original Text
-------------
In section 4.2:

The 'sos' service type describes emergency services requiring an immediate response, typically offered by various branches of the
government or other public institutions.

Corrected Text
--------------
In section 4.2, add a reference:

The 'sos' service type describes emergency services requiring an immediate response, typically offered by various branches of the
government or other public institutions. [IRC]

In section 7.2, add a reference:

[IRC] Service Regulations annexed to the International Radiotelegraphic
Convention, Berlin, 1906, section 6. a., article XVI.
https://babel= .hathitrust.org/cgi/pt?id=3Dhvd.32044103239133&view=3D1up&seq=3D36<= /a>


Notes
-----
The referenced section of the protocols of the convention is "Ships in= distress make use of the following signal: . . . - - - . . .=C2=A0 repeate= d at short intervals. ...".

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5031 (draft-ietf-ecrit-service-urn-07)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A Uniform Res= ource Name (URN) for Emergency and Other Well-Known Services
Publication Date=C2=A0 =C2=A0 : January 2008
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: H. Schulzrinne
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Emergency Context = Resolution with Internet Technologies RAI
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Real-time App= lications and Infrastructure
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
--000000000000594b1005b6d748eb-- From nobody Sat Dec 19 12:54:18 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4AD3A0F41 for ; Sat, 19 Dec 2020 12:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFtEhCruzPzH for ; Sat, 19 Dec 2020 12:54:14 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F3D3A0F3D for ; Sat, 19 Dec 2020 12:54:14 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id c7so5553033qke.1 for ; Sat, 19 Dec 2020 12:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7hrai0dq7HSEN0IvXFhKGwCUpruZMNV0oYpyB6Pq1cY=; b=nm9oS0LSVFqxs8NZDmR1fsr+Y8Rq2ednzpxfDnOUlfc5gnbnXAqFLn3jxe63KIizKS wmgcslgytw3ayej7K9KgztTpOvcjukJMqAfXZf2Bvm9JW8iH88kNQErwTghxmVmvi8t2 qQlf3brYgXEm3gFhVFGscoYJtyGZD5QWOCeElCJil5iJ5DJXcSgSQO5IsY8sa4I5N/Ot Bn1vRP6pWgvE6sH9qn4kUnYWuhlg7UCQi/sTcAZyeLvOtN3ATAnMh1v6cEwms2I2+3DB a8IyiFOmW646V+FZbhT76KF2tcAiXb0aEzlake3tritDSrwq8qbNTxqrGo5+HCMtJ0vW kKfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7hrai0dq7HSEN0IvXFhKGwCUpruZMNV0oYpyB6Pq1cY=; b=rQx6hAkVK3d8wjZD7o6kq3I4uENeJmjzShv7bOhabjEjJGIO7L8pjwkMj3ff8kpbMT oOqcV+k5M8WmGswhRUdg37COWAU6nmo2VEyNX3JiAkzrTgez3b8xw4WB4ggEYv84NJJb 6gA/b8OqDEuhfh5GIeDRISNyu9BIJyQnCzHZuARcXhyZ/xyJ3BEV0p6JC1DbTKZxxAuz h+3CnTxaqCMpWDmSbaJg4GTLU7O86VU3kmNyQ4sw1qrlzXsW7N2++69/MaVKYXXD357u 2pR9k5lH1pmLfrlak3F5oLHm9oNYgC76HXAWN3n4owtc4OiGUkcIN4oBgUV2YMt1J1yg YfmQ== X-Gm-Message-State: AOAM532hE27WgPTLxTwN3FdKdnfzTd3dLkX6t9a08tc4KQBH+fkKC/pZ HvSft9alNEx1Joxc7BNOe2broQ== X-Google-Smtp-Source: ABdhPJy33jEZM6VLOdvufRTovrqtnp4fBtvbTcD9mseL4kWMItUfFYjqrJWbyxXe6CyrENUyBHXmGw== X-Received: by 2002:a05:620a:a9c:: with SMTP id v28mr11363012qkg.107.1608411253573; Sat, 19 Dec 2020 12:54:13 -0800 (PST) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id h67sm8289070qkd.107.2020.12.19.12.54.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Dec 2020 12:54:13 -0800 (PST) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BABE21CA-FBDF-4435-8571-A594F6C8E34F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 19 Dec 2020 15:54:11 -0500 In-Reply-To: Cc: RFC Errata System , Allison Mankin , Henning Schulzrinne , "Dale R. Worley" , ECRIT To: Barry Leiba References: <20201219194859.7F89DF4074D@rfc-editor.org> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Ecrit] [Editorial Errata Reported] RFC5031 (6359) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2020 20:54:17 -0000 --Apple-Mail=_BABE21CA-FBDF-4435-8571-A594F6C8E34F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with you. Sos is a convenient, well understood term used for = emergencies and we don=E2=80=99t need a reference for it. So, I would = recommend =E2=80=9CReject=E2=80=9D Brian > On Dec 19, 2020, at 3:43 PM, Barry Leiba = wrote: >=20 > Hi, Dale, and thanks for taking the time to file this. >=20 > I=E2=80=99m quite sure this isn=E2=80=99t really =E2=80=9Cerrata=E2=80=9D= , though, in that there was never an intent to include a reference that = explains the background of why it=E2=80=99s called =E2=80=9Csos=E2=80=9D. = And while the reference might be good for amusement, it doesn=E2=80=99t = relate to this usage... the RFC itself explains everything necessary, = and the only thing the reference adds is a pointer to why it=E2=80=99s = called =E2=80=9Csos=E2=80=9D. >=20 > So unless the working group (which is CCed here) thinks it=E2=80=99s = worth making this =E2=80=9CHeld For Document Update=E2=80=9D, I=E2=80=99m = inclined to mark it =E2=80=9CRejected=E2=80=9D. Anyone ecrit working = group denizens care to comment? >=20 > Barry >=20 > On Sat, Dec 19, 2020 at 2:49 PM RFC Errata System = > wrote: > The following errata report has been submitted for RFC5031, > "A Uniform Resource Name (URN) for Emergency and Other Well-Known = Services". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6359 = >=20 > -------------------------------------- > Type: Editorial > Reported by: Dale R. Worley > >=20 > Section: 4.2, 7.2 >=20 > Original Text > ------------- > In section 4.2: >=20 > The 'sos' service type describes emergency services requiring an > immediate response, typically offered by various branches of the > government or other public institutions. >=20 > Corrected Text > -------------- > In section 4.2, add a reference: >=20 > The 'sos' service type describes emergency services requiring an > immediate response, typically offered by various branches of the > government or other public institutions. [IRC] >=20 > In section 7.2, add a reference: >=20 > [IRC] Service Regulations annexed to the International = Radiotelegraphic > Convention, Berlin, 1906, section 6. a., article XVI. > = https://babel.hathitrust.org/cgi/pt?id=3Dhvd.32044103239133&view=3D1up&seq= =3D36 = >=20 >=20 > Notes > ----- > The referenced section of the protocols of the convention is "Ships in = distress make use of the following signal: . . . - - - . . . repeated = at short intervals. ...". >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5031 (draft-ietf-ecrit-service-urn-07) > -------------------------------------- > Title : A Uniform Resource Name (URN) for Emergency and = Other Well-Known Services > Publication Date : January 2008 > Author(s) : H. Schulzrinne > Category : PROPOSED STANDARD > Source : Emergency Context Resolution with Internet = Technologies RAI > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_BABE21CA-FBDF-4435-8571-A594F6C8E34F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree with you.  Sos is a convenient, well understood term used for = emergencies and we don=E2=80=99t need a reference for it.  So, I = would recommend =E2=80=9CReject=E2=80=9D

Brian

On Dec 19, 2020, at 3:43 PM, Barry Leiba <barryleiba@computer.org> wrote:

Hi, Dale, and thanks for taking the time to file = this.

I=E2=80=99m quite sure this isn=E2=80=99t really = =E2=80=9Cerrata=E2=80=9D, though, in that there was never an intent to = include a reference that explains the background of why it=E2=80=99s = called =E2=80=9Csos=E2=80=9D.  And while the reference might be = good for amusement, it doesn=E2=80=99t relate to this usage... the RFC = itself explains everything necessary, and the only thing the reference = adds is a pointer to why it=E2=80=99s called =E2=80=9Csos=E2=80=9D.
<= div dir=3D"auto" class=3D"">
So unless the working group (which is CCed here) thinks = it=E2=80=99s worth making this =E2=80=9CHeld For Document Update=E2=80=9D,= I=E2=80=99m inclined to mark it =E2=80=9CRejected=E2=80=9D.  = Anyone ecrit working group denizens care to comment?

Barry

On Sat, Dec = 19, 2020 at 2:49 PM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has been = submitted for RFC5031,
"A Uniform Resource Name (URN) for Emergency and Other Well-Known = Services".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6359

--------------------------------------
Type: Editorial
Reported by: Dale R. Worley <worley@ariadne.com>

Section: 4.2, 7.2

Original Text
-------------
In section 4.2:

The 'sos' service type describes emergency services requiring an
immediate response, typically offered by various branches of the
government or other public institutions.

Corrected Text
--------------
In section 4.2, add a reference:

The 'sos' service type describes emergency services requiring an
immediate response, typically offered by various branches of the
government or other public institutions. [IRC]

In section 7.2, add a reference:

[IRC] Service Regulations annexed to the International = Radiotelegraphic
Convention, Berlin, 1906, section 6. a., article XVI.
https://babel.hathitrust.org/cgi/pt?id=3Dhvd.32044103239133&= ;view=3D1up&seq=3D36


Notes
-----
The referenced section of the protocols of the convention is "Ships in = distress make use of the following signal: . . . - - - . . .  = repeated at short intervals. ...".

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
= rejected. When a decision is reached, the verifying party 
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5031 (draft-ietf-ecrit-service-urn-07)
--------------------------------------
Title               : A Uniform = Resource Name (URN) for Emergency and Other Well-Known Services
Publication Date    : January 2008
Author(s)           : H. Schulzrinne
Category            : PROPOSED STANDARD
Source              : Emergency = Context Resolution with Internet Technologies RAI
Area                : Real-time = Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
Ecrit = mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

= --Apple-Mail=_BABE21CA-FBDF-4435-8571-A594F6C8E34F-- From nobody Sat Dec 19 17:18:15 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8573A03F8 for ; Sat, 19 Dec 2020 17:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=columbia.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5wk2nOxlDs8 for ; Sat, 19 Dec 2020 17:18:10 -0800 (PST) Received: from mx0a-00364e01.pphosted.com (mx0a-00364e01.pphosted.com [148.163.135.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06D13A03F5 for ; Sat, 19 Dec 2020 17:18:10 -0800 (PST) Received: from pps.filterd (m0167069.ppops.net [127.0.0.1]) by mx0a-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0BK15Thg031013 for ; Sat, 19 Dec 2020 20:18:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=pps01; bh=NxLBfG7tX6lHTKW5T1OrWQs+rw0Oh5hq0Mqsa25ooTg=; b=QazGDUi/QoLG7CB0fkjRx4AJZroTXAp7F/2/hJVCm4tnSaguKPQMliVItIQhFpCXbbZr oPrGdYbkDY9OjTmbWEteuhJ+aqoXMzN763nl3SO4F2U1JKjNSWwgN6AOb1UwPv51NVVQ PDvB4UuvkOjD7+v618VYgweDxfdJzahn7iqVVWLFveOfJto0GG/qfryVHQYjJBuvhX2b x7KYdsKp0SzMNyA0o4RyFZPn3YRYdafdvHl7hxgD3zWom3o3P0JT5Lq/qX32DwlU5Vo4 U0EQYZofqZaCjDMEgaWBUA/fuyPtORk8nW6uAWp7/YzxzY1SJuADSm9FmqqvEb2GzVhO /w== Received: from sendprodmail11.cc.columbia.edu (sendprodmail11.cc.columbia.edu [128.59.72.19]) by mx0a-00364e01.pphosted.com with ESMTP id 35hbdpuc24-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 19 Dec 2020 20:18:10 -0500 Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by sendprodmail11.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 0BK1I9d0014262 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 19 Dec 2020 20:18:09 -0500 Received: by mail-qk1-f199.google.com with SMTP id n190so5105573qkf.18 for ; Sat, 19 Dec 2020 17:18:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NxLBfG7tX6lHTKW5T1OrWQs+rw0Oh5hq0Mqsa25ooTg=; b=eNcmeaqfPP8MiBI+XCnHDJH2WrTqQNL0kyZDpX8HkPxYBDhcS5VP9ccXpgRL+Jtrtj Kp0GyolYNemalUEdmR2I9MJ1UoPyYVmudVeXwFwWTI9b8K/KdqzNwaK4Oo1g8taRMRqM 9dQ/P0gelwGTnfUVjmKn/e69/9umOMm32nf7oLEyHyIdI5HnPS5ttPOjm0xYPRYDYrRu ZJzSs0v+p01ua7eeUn4N5/p3tkVYMlPxKEI90GbwKXYwjljykT/D7AFJzIMSkkGoBXLl uan6uFCLWDrCI++kOa8XODTIYaqm8lvo1CnU4qWxXiKzkZUOxH55uTq1Cno1ydz0lG1v mmDQ== X-Gm-Message-State: AOAM530qI+txtv7240HgFUkQzPgEBJS0jaSZftFGAGVt/Vy7ksN57x+a o+WJEhmh9R9v8yygxv8weV5m7fjVZiYqqDRRAhAF5XE+kYqYvmyxpaVPSHfVPQD8JPcBcPzxu6S 4h7HgKSK0F/VcjaFRFmzze0ZgqQyjKQ== X-Received: by 2002:ad4:4761:: with SMTP id d1mr12059147qvx.12.1608427088659; Sat, 19 Dec 2020 17:18:08 -0800 (PST) X-Google-Smtp-Source: ABdhPJzFwf5uRkDD2Dj5ODb74gQal+GX2SW5TIWTtrkeuQTvB4dkr3/05yrXuhMCGgPH0kq8ECRCAG8YcBCVS9hCslk= X-Received: by 2002:ad4:4761:: with SMTP id d1mr12059131qvx.12.1608427088066; Sat, 19 Dec 2020 17:18:08 -0800 (PST) MIME-Version: 1.0 References: <20201219194859.7F89DF4074D@rfc-editor.org> In-Reply-To: From: Henning Schulzrinne Date: Sat, 19 Dec 2020 20:17:41 -0500 Message-ID: To: Barry Leiba Cc: RFC Errata System , Allison Mankin , ECRIT , Hgs Ecrit , Roger Marshall , "Murray S. Kucherawy" , "Dale R. Worley" Content-Type: multipart/alternative; boundary="0000000000003b548705b6db1d80" X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-19_16:2020-12-19, 2020-12-19 signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 suspectscore=0 bulkscore=10 lowpriorityscore=10 adultscore=0 spamscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 priorityscore=1501 mlxscore=0 impostorscore=10 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012200005 Archived-At: Subject: Re: [Ecrit] [Editorial Errata Reported] RFC5031 (6359) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2020 01:18:14 -0000 --0000000000003b548705b6db1d80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agree. On Sat, Dec 19, 2020 at 3:43 PM Barry Leiba wrote= : > Hi, Dale, and thanks for taking the time to file this. > > I=E2=80=99m quite sure this isn=E2=80=99t really =E2=80=9Cerrata=E2=80=9D= , though, in that there was never > an intent to include a reference that explains the background of why it= =E2=80=99s > called =E2=80=9Csos=E2=80=9D. And while the reference might be good for = amusement, it > doesn=E2=80=99t relate to this usage... the RFC itself explains everythin= g > necessary, and the only thing the reference adds is a pointer to why it= =E2=80=99s > called =E2=80=9Csos=E2=80=9D. > > So unless the working group (which is CCed here) thinks it=E2=80=99s wort= h making > this =E2=80=9CHeld For Document Update=E2=80=9D, I=E2=80=99m inclined to = mark it =E2=80=9CRejected=E2=80=9D. > Anyone ecrit working group denizens care to comment? > > Barry > > On Sat, Dec 19, 2020 at 2:49 PM RFC Errata System < > rfc-editor@rfc-editor.org> wrote: > >> The following errata report has been submitted for RFC5031, >> "A Uniform Resource Name (URN) for Emergency and Other Well-Known >> Services". >> >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid6359 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Dale R. Worley >> >> Section: 4.2, 7.2 >> >> Original Text >> ------------- >> In section 4.2: >> >> The 'sos' service type describes emergency services requiring an >> immediate response, typically offered by various branches of the >> government or other public institutions. >> >> Corrected Text >> -------------- >> In section 4.2, add a reference: >> >> The 'sos' service type describes emergency services requiring an >> immediate response, typically offered by various branches of the >> government or other public institutions. [IRC] >> >> In section 7.2, add a reference: >> >> [IRC] Service Regulations annexed to the International Radiotelegraphic >> Convention, Berlin, 1906, section 6. a., article XVI. >> https://babel.hathitrust.org/cgi/pt?id=3Dhvd.32044103239133&view=3D1up&s= eq=3D36 >> >> >> Notes >> ----- >> The referenced section of the protocols of the convention is "Ships in >> distress make use of the following signal: . . . - - - . . . repeated a= t >> short intervals. ...". >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5031 (draft-ietf-ecrit-service-urn-07) >> -------------------------------------- >> Title : A Uniform Resource Name (URN) for Emergency and >> Other Well-Known Services >> Publication Date : January 2008 >> Author(s) : H. Schulzrinne >> Category : PROPOSED STANDARD >> Source : Emergency Context Resolution with Internet >> Technologies RAI >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> > --0000000000003b548705b6db1d80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agree.

On Sat, Dec 19, 2020 at 3:43 PM Barry Leiba &= lt;barryleiba@computer.org&g= t; wrote:
Hi, Dale, and thanks for taking the time to file this.

I=E2=80=99m quite sure this isn= =E2=80=99t really =E2=80=9Cerrata=E2=80=9D, though, in that there was never= an intent to include a reference that explains the background of why it=E2= =80=99s called =E2=80=9Csos=E2=80=9D.=C2=A0 And while the reference might b= e good for amusement, it doesn=E2=80=99t relate to this usage... the RFC it= self explains everything necessary, and the only thing the reference adds i= s a pointer to why it=E2=80=99s called =E2=80=9Csos=E2=80=9D.

So unless the working group (which is= CCed here) thinks it=E2=80=99s worth making this =E2=80=9CHeld For Documen= t Update=E2=80=9D, I=E2=80=99m inclined to mark it =E2=80=9CRejected=E2=80= =9D.=C2=A0 Anyone ecrit working group denizens care to comment?

Barry

On Sat, Dec 19, 2020 at 2= :49 PM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has b= een submitted for RFC5031,
"A Uniform Resource Name (URN) for Emergency and Other Well-Known Serv= ices".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6359

--------------------------------------
Type: Editorial
Reported by: Dale R. Worley <worley@ariadne.com>

Section: 4.2, 7.2

Original Text
-------------
In section 4.2:

The 'sos' service type describes emergency services requiring an immediate response, typically offered by various branches of the
government or other public institutions.

Corrected Text
--------------
In section 4.2, add a reference:

The 'sos' service type describes emergency services requiring an immediate response, typically offered by various branches of the
government or other public institutions. [IRC]

In section 7.2, add a reference:

[IRC] Service Regulations annexed to the International Radiotelegraphic
Convention, Berlin, 1906, section 6. a., article XVI.
https://babel= .hathitrust.org/cgi/pt?id=3Dhvd.32044103239133&view=3D1up&seq=3D36<= /a>


Notes
-----
The referenced section of the protocols of the convention is "Ships in= distress make use of the following signal: . . . - - - . . .=C2=A0 repeate= d at short intervals. ...".

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5031 (draft-ietf-ecrit-service-urn-07)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A Uniform Res= ource Name (URN) for Emergency and Other Well-Known Services
Publication Date=C2=A0 =C2=A0 : January 2008
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: H. Schulzrinne
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Emergency Context = Resolution with Internet Technologies RAI
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Real-time App= lications and Infrastructure
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
--0000000000003b548705b6db1d80-- From nobody Mon Dec 21 16:03:44 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3B73A1368 for ; Mon, 21 Dec 2020 16:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sHPtlTojNXN for ; Mon, 21 Dec 2020 16:03:40 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id BC84C3A1366 for ; Mon, 21 Dec 2020 16:03:40 -0800 (PST) Received: from [169.254.250.14] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 21 Dec 2020 16:04:18 -0800 From: "Randall Gellens" To: "Barry Leiba" Cc: "RFC Errata System" , allison.mankin@gmail.com, hgs+ecrit@cs.columbia.edu, worley@ariadne.com, ecrit@ietf.org Date: Mon, 21 Dec 2020 16:03:39 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: <510260B0-59F4-443C-BD41-2B20C54122E7@randy.pensive.org> In-Reply-To: References: <20201219194859.7F89DF4074D@rfc-editor.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_E13C79FC-86E5-443E-A431-3AFEEABA684B_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[538, 3986], "plain":[207, 3035], "uuid":"D04DCDF1-1164-4755-8105-CA4307574486"}] Archived-At: Subject: Re: [Ecrit] [Editorial Errata Reported] RFC5031 (6359) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 00:03:43 -0000 --=_MailMate_E13C79FC-86E5-443E-A431-3AFEEABA684B_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Can you reject with a note saying "Thanks, the reference is entertaining and appreciated, but doesn't add to a reader's understanding of the RFC"? --Randall On 19 Dec 2020, at 12:43, Barry Leiba wrote: > Hi, Dale, and thanks for taking the time to file this. > > I’m quite sure this isn’t really “errata”, though, in that > there was never > an intent to include a reference that explains the background of why > it’s > called “sos”. And while the reference might be good for > amusement, it > doesn’t relate to this usage... the RFC itself explains everything > necessary, and the only thing the reference adds is a pointer to why > it’s > called “sos”. > > So unless the working group (which is CCed here) thinks it’s worth > making > this “Held For Document Update”, I’m inclined to mark it > “Rejected”. > Anyone ecrit working group denizens care to comment? > > Barry > > On Sat, Dec 19, 2020 at 2:49 PM RFC Errata System > > wrote: > >> The following errata report has been submitted for RFC5031, >> "A Uniform Resource Name (URN) for Emergency and Other Well-Known >> Services". >> >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid6359 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Dale R. Worley >> >> Section: 4.2, 7.2 >> >> Original Text >> ------------- >> In section 4.2: >> >> The 'sos' service type describes emergency services requiring an >> immediate response, typically offered by various branches of the >> government or other public institutions. >> >> Corrected Text >> -------------- >> In section 4.2, add a reference: >> >> The 'sos' service type describes emergency services requiring an >> immediate response, typically offered by various branches of the >> government or other public institutions. [IRC] >> >> In section 7.2, add a reference: >> >> [IRC] Service Regulations annexed to the International >> Radiotelegraphic >> Convention, Berlin, 1906, section 6. a., article XVI. >> https://babel.hathitrust.org/cgi/pt?id=hvd.32044103239133&view=1up&seq=36 >> >> >> Notes >> ----- >> The referenced section of the protocols of the convention is "Ships >> in >> distress make use of the following signal: . . . - - - . . . >> repeated at >> short intervals. ...". >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5031 (draft-ietf-ecrit-service-urn-07) >> -------------------------------------- >> Title : A Uniform Resource Name (URN) for Emergency and >> Other Well-Known Services >> Publication Date : January 2008 >> Author(s) : H. Schulzrinne >> Category : PROPOSED STANDARD >> Source : Emergency Context Resolution with Internet >> Technologies RAI >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_MailMate_E13C79FC-86E5-443E-A431-3AFEEABA684B_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Can you reject with a note saying "Thanks, the reference i= s entertaining and appreciated, but doesn't add to a reader's understandi= ng of the RFC"?

--Randall

On 19 Dec 2020, at 12:43, Barry Leiba wrote:

Hi, Dale, and thanks for taking the time to file this.

I=E2=80=99m quite sure t= his isn=E2=80=99t really =E2=80=9Cerrata=E2=80=9D, though, in that there = was never an intent to include a reference that explains the background o= f why it=E2=80=99s called =E2=80=9Csos=E2=80=9D.=C2=A0 And while the refe= rence might be good for amusement, it doesn=E2=80=99t relate to this usag= e... the RFC itself explains everything necessary, and the only thing the= reference adds is a pointer to why it=E2=80=99s called =E2=80=9Csos=E2=80= =9D.

So unless the wor= king group (which is CCed here) thinks it=E2=80=99s worth making this =E2= =80=9CHeld For Document Update=E2=80=9D, I=E2=80=99m inclined to mark it = =E2=80=9CRejected=E2=80=9D.=C2=A0 Anyone ecrit working group denizens car= e to comment?

Barry

On Sat, Dec 19, 2020 at 2:49 PM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has been submitte= d for RFC5031,
"A Uniform Resource Name (URN) for Emergency and Other Well-Known Se= rvices".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6359

--------------------------------------
Type: Editorial
Reported by: Dale R. Worley <worley@ariadne.com>

Section: 4.2, 7.2

Original Text
-------------
In section 4.2:

The 'sos' service type describes emergency services requiring an<= br> immediate response, typically offered by various branches of the
government or other public institutions.

Corrected Text
--------------
In section 4.2, add a reference:

The 'sos' service type describes emergency services requiring an<= br> immediate response, typically offered by various branches of the
government or other public institutions. [IRC]

In section 7.2, add a reference:

[IRC] Service Regulations annexed to the International Radiotelegraphic Convention, Berlin, 1906, section 6. a., article XVI.
https://b= abel.hathitrust.org/cgi/pt?id=3Dhvd.32044103239133&view=3D1up&seq= =3D36


Notes
-----
The referenced section of the protocols of the convention is "Ships = in distress make use of the following signal: . . . - - - . . .=C2=A0 rep= eated at short intervals. ...".

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, p= lease
use "Reply All" to discuss whether it should be verified or
= rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5031 (draft-ietf-ecrit-service-urn-07)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A Uniform R= esource Name (URN) for Emergency and Other Well-Known Services
Publication Date=C2=A0 =C2=A0 : January 2008
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: H. Schulzrinne
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
= Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Emergency Contex= t Resolution with Internet Technologies RAI
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Real-time A= pplications and Infrastructure
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

______________________= _________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--=_MailMate_E13C79FC-86E5-443E-A431-3AFEEABA684B_=-- From nobody Mon Dec 21 18:48:15 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD5B3A08AF for ; Mon, 21 Dec 2020 18:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbJavuW30CdU for ; Mon, 21 Dec 2020 18:48:10 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FFA53A08AE for ; Mon, 21 Dec 2020 18:48:10 -0800 (PST) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id rXdHk4bTMmGgIrXibkQa1f; Tue, 22 Dec 2020 02:48:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1608605289; bh=HnsPwS7DkEctnLRStQ17DsGCFcRqi6uWLhA+uOwC3K8=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:MIME-Version:Content-Type; b=po+2IVxH7VcHsfQTtdn46tUjbwnBl+FUREkoP/Vbm4bdU9DsdkhF0eqzYmhv0+4M8 Lm2MzgvnXtXTl5ezgAg7oSt1TUA2Je0w1wkW/A/YXv0RkuqjCc7JDshmymNJdqhBrj iQagE9Ml5tNsw6Pnc+KfCaW9pH5DlSFcNPqwipB/rm9Cf5l09qF1dtUv7gI6xKBMJi WxOacp7hsM1hmZTvVkCuFCWcA+Kv5YKwKdNnu87d5nsF5VULEkgYXu+j2LFirjarbx u+gj3T1J6Jd4khwK5FK4jH2zbm3KfRJKsI0BxcBKxatRXt7EJjdl0WsjiQickGV4gr C1pa1VbE7zpaw== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-14v.sys.comcast.net with ESMTPA id rXiXkF7S5l029rXiYkSJv3; Tue, 22 Dec 2020 02:48:07 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 0BM2m40V030768; Mon, 21 Dec 2020 21:48:04 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 0BM2m3A0030761; Mon, 21 Dec 2020 21:48:03 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Barry Leiba Cc: rfc-editor@rfc-editor.org, allison.mankin@gmail.com, ecrit@ietf.org, hgs+ecrit@cs.columbia.edu, roger.marshall@comtechtel.com, superuser@gmail.com In-Reply-To: (barryleiba@computer.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 21 Dec 2020 21:48:01 -0500 Message-ID: <87r1nir1y6.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ecrit] [Editorial Errata Reported] RFC5031 (6359) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 02:48:14 -0000 Barry Leiba writes: > I=E2=80=99m quite sure this isn=E2=80=99t really =E2=80=9Cerrata=E2=80=9D= , though, in that there was never > an intent to include a reference that explains the background of why it= =E2=80=99s > called =E2=80=9Csos=E2=80=9D. And while the reference might be good for = amusement, it > doesn=E2=80=99t relate to this usage... the RFC itself explains everything > necessary, and the only thing the reference adds is a pointer to why it= =E2=80=99s > called =E2=80=9Csos=E2=80=9D. Well, y'all can do whatever you want, of course. Personally, I've always wanted to know the history of the standardization of "SOS", and I see nothing improper to providing a reference to the first standard specifying "SOS", which is actually why that combination of letters is used in the RFC. Dale From nobody Mon Dec 21 19:26:49 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02853A0962 for ; Mon, 21 Dec 2020 19:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vLPBlP7d4wz for ; Mon, 21 Dec 2020 19:26:46 -0800 (PST) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3193A094E for ; Mon, 21 Dec 2020 19:26:46 -0800 (PST) Received: by mail-lf1-f47.google.com with SMTP id a12so28668557lfl.6 for ; Mon, 21 Dec 2020 19:26:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hQRE/ZkQfGX2patyWyhPXRcsXrqGCg96DtV9Gh3yD7Q=; b=IZHI0sCyn630sQgXwI9oL3QDU9WBeq0LrwHQDQwB0LtbymOjgldUfHraW6Q6T/S3jO j7F+9vPJS+mmtSjCJw8XTt4EGhYjgC5FS+qphy3SqlKuOVyL8i9upTvoSOR/223/7PWP 4aJSVC8WKWnnqbZ8qRuMawbPlAHtxCwWj5K99qk324vzFrdSyPPlJe6QoALf0FIS7g2G MquhON2KJ85CBN4JzEOQle/NxIrXJ9flhPygklfafyU+fkbSNlYPhtK3tOb/r672QqIy JGJjNpssnwANCZdzh53kBg7Apuo3x9w1U7yxb7er3WQeICrsvP98GcAVXAGxIDyiQa/c al/Q== X-Gm-Message-State: AOAM531ELoexU1XG0w1LnSrsfW3E0k96e6YTxKXUYyTC+y/Bx44gEvO7 RL/waJlqvud32eLrklzhs/BASVCl8QKk+7JBLx8= X-Google-Smtp-Source: ABdhPJyZvEg1wLZVsC1a22q81y8li/+pnDsbogfO7hXt37ynpdu1anzh+9xcjhB+ag00fNPL7t9vsZA2NYuvJOFPmcI= X-Received: by 2002:a2e:9756:: with SMTP id f22mr8610715ljj.65.1608607604422; Mon, 21 Dec 2020 19:26:44 -0800 (PST) MIME-Version: 1.0 References: <87r1nir1y6.fsf@hobgoblin.ariadne.com> In-Reply-To: <87r1nir1y6.fsf@hobgoblin.ariadne.com> From: Barry Leiba Date: Mon, 21 Dec 2020 22:26:33 -0500 Message-ID: To: "Dale R. Worley" Cc: allison.mankin@gmail.com, ecrit@ietf.org, hgs+ecrit@cs.columbia.edu, rfc-editor@rfc-editor.org, roger.marshall@comtechtel.com, superuser@gmail.com Content-Type: multipart/alternative; boundary="000000000000d83a4705b705242a" Archived-At: Subject: Re: [Ecrit] [Editorial Errata Reported] RFC5031 (6359) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 03:26:48 -0000 --000000000000d83a4705b705242a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oh, nothing improper at all about including a reference, and if we were writing or revising the document now we might well include it. This is just an errata-process issue, nothing more. Barry On Mon, Dec 21, 2020 at 9:48 PM Dale R. Worley wrote: > Barry Leiba writes: > > I=E2=80=99m quite sure this isn=E2=80=99t really =E2=80=9Cerrata=E2=80= =9D, though, in that there was > never > > an intent to include a reference that explains the background of why it= =E2=80=99s > > called =E2=80=9Csos=E2=80=9D. And while the reference might be good fo= r amusement, it > > doesn=E2=80=99t relate to this usage... the RFC itself explains everyth= ing > > necessary, and the only thing the reference adds is a pointer to why it= =E2=80=99s > > called =E2=80=9Csos=E2=80=9D. > > Well, y'all can do whatever you want, of course. Personally, I've > always wanted to know the history of the standardization of "SOS", and I > see nothing improper to providing a reference to the first standard > specifying "SOS", which is actually why that combination of letters is > used in the RFC. > > Dale > --000000000000d83a4705b705242a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oh, nothing improper at all about including a reference, = and if we were writing or revising the document now we might well include i= t.=C2=A0 This is just an errata-process issue, nothing more.

Barry

On Mon, Dec 21, 2020 at 9:4= 8 PM Dale R. Worley <worley@ariadn= e.com> wrote:
Barry Leiba <barryleiba@computer.org> writes:
> I=E2=80=99m quite sure this isn=E2=80=99t really =E2=80=9Cerrata=E2=80= =9D, though, in that there was never
> an intent to include a reference that explains the background of why i= t=E2=80=99s
> called =E2=80=9Csos=E2=80=9D.=C2=A0 And while the reference might be g= ood for amusement, it
> doesn=E2=80=99t relate to this usage... the RFC itself explains everyt= hing
> necessary, and the only thing the reference adds is a pointer to why i= t=E2=80=99s
> called =E2=80=9Csos=E2=80=9D.

Well, y'all can do whatever you want, of course.=C2=A0 Personally, I= 9;ve
always wanted to know the history of the standardization of "SOS"= , and I
see nothing improper to providing a reference to the first standard
specifying "SOS", which is actually why that combination of lette= rs is
used in the RFC.

Dale
--000000000000d83a4705b705242a-- From nobody Tue Dec 22 09:38:52 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232AD3A11BD; Tue, 22 Dec 2020 09:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7kAx0k6tdKS; Tue, 22 Dec 2020 09:38:49 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804753A11BC; Tue, 22 Dec 2020 09:38:49 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 8F802F40752; Tue, 22 Dec 2020 09:38:31 -0800 (PST) To: worley@ariadne.com, hgs+ecrit@cs.columbia.edu X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: barryleiba@computer.org, iesg@ietf.org, ecrit@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20201222173831.8F802F40752@rfc-editor.org> Date: Tue, 22 Dec 2020 09:38:31 -0800 (PST) Archived-At: Subject: [Ecrit] [Errata Rejected] RFC5031 (6359) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 17:38:51 -0000 The following errata report has been rejected for RFC5031, "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6359 -------------------------------------- Status: Rejected Type: Editorial Reported by: Dale R. Worley Date Reported: 2020-12-19 Rejected by: Barry Leiba (IESG) Section: 4.2, 7.2 Original Text ------------- In section 4.2: The 'sos' service type describes emergency services requiring an immediate response, typically offered by various branches of the government or other public institutions. Corrected Text -------------- In section 4.2, add a reference: The 'sos' service type describes emergency services requiring an immediate response, typically offered by various branches of the government or other public institutions. [IRC] In section 7.2, add a reference: [IRC] Service Regulations annexed to the International Radiotelegraphic Convention, Berlin, 1906, section 6. a., article XVI. https://babel.hathitrust.org/cgi/pt?id=hvd.32044103239133&view=1up&seq=36 Notes ----- The referenced section of the protocols of the convention is "Ships in distress make use of the following signal: . . . - - - . . . repeated at short intervals. ...". --VERIFIER NOTES-- Thanks for suggesting the reference, and it's interesting to have a source that shows where the "sos" term started. It's not an error, though: the RFC is correct as published, and there was never an intent to cite a reference there. So as an errata report, this is rejected... with encouragement for interested readers to look at the historic reference. -------------------------------------- RFC5031 (draft-ietf-ecrit-service-urn-07) -------------------------------------- Title : A Uniform Resource Name (URN) for Emergency and Other Well-Known Services Publication Date : January 2008 Author(s) : H. Schulzrinne Category : PROPOSED STANDARD Source : Emergency Context Resolution with Internet Technologies RAI Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Tue Dec 22 19:42:24 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620BC3A08E7 for ; Tue, 22 Dec 2020 19:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3s7n4AaC5YE for ; Tue, 22 Dec 2020 19:42:20 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B39153A08D9 for ; Tue, 22 Dec 2020 19:42:20 -0800 (PST) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id rujnkVfadbBITrv2ZkaTA4; Wed, 23 Dec 2020 03:42:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1608694939; bh=ra9G9m81Wteytp4EAIXNfN6HDv8+JhP/lbUAn+kGD74=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=e5Npx14LsOojJiZhmjpDEFI2u55Jc6GT2doHOe0q3lqjJaj+maOjw+mdusxtgBLN/ YzHCbIGT+E39uSvltFOpZsFmclDMVxUwiymYrD9KiqmQRHX/xjAXX5Jos+7LzzxZgG 4JmJKKZ5dsygLyr1jkS/aJu743w6is5fWK7wamAbntsamu4FVW5VsPHR3w4jX2sKNo Fcz2VexD3jxk032uESGFzOss0jP9c0kf+WzA6wxmcMBB5GswE223BR2IcJZFqOSyhR uZI5F1tybPAnEPErzICOtlHGW3i4mqYBXLKR622DrDY2D4AGPt42VCBjvj7LYK88Hq 7axQ1VDRBwqQw== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-02v.sys.comcast.net with ESMTPA id rv2TkDGPVoNaKrv2UkpIT8; Wed, 23 Dec 2020 03:42:16 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 0BN3gDQF006054; Tue, 22 Dec 2020 22:42:13 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 0BN3gBRN006049; Tue, 22 Dec 2020 22:42:11 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Barry Leiba Cc: allison.mankin@gmail.com, ecrit@ietf.org, hgs+ecrit@cs.columbia.edu, rfc-editor@rfc-editor.org, roger.marshall@comtechtel.com, superuser@gmail.com In-Reply-To: (barryleiba@computer.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 22 Dec 2020 22:42:11 -0500 Message-ID: <874kkdw5m4.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [Ecrit] [Editorial Errata Reported] RFC5031 (6359) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 03:42:22 -0000 Barry Leiba writes: > Oh, nothing improper at all about including a reference, and if we were > writing or revising the document now we might well include it. This is > just an errata-process issue, nothing more. There is "hold for document update", IIRC. Dale