[salud] Reply to Pearl Liang (IANA)
worley@ariadne.com (Dale R. Worley) Fri, 25 April 2014 19:59 UTC
Return-Path: <worley@ariadne.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com
(Postfix) with ESMTP id 123421A03CD for <salud@ietfa.amsl.com>;
Fri, 25 Apr 2014 12:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.2
X-Spam-Level: **
X-Spam-Status: No, score=2.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,
DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6,
J_CHICKENPOX_84=0.6, MANGLED_BELOW=2.3] autolearn=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 8gY3r1Oxbslt for
<salud@ietfa.amsl.com>; Fri, 25 Apr 2014 12:59:42 -0700 (PDT)
Received: from qmta04.westchester.pa.mail.comcast.net
(qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40])
by ietfa.amsl.com (Postfix) with ESMTP id 9CB831A05D1 for <salud@ietf.org>;
Fri, 25 Apr 2014 12:59:41 -0700 (PDT)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by
qmta04.westchester.pa.mail.comcast.net with comcast id uCiA1n0051GhbT854Kzbdj;
Fri, 25 Apr 2014 19:59:35 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by
omta07.westchester.pa.mail.comcast.net with comcast id uKzZ1n00x1KKtkw3TKzamB;
Fri, 25 Apr 2014 19:59:34 +0000
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 s3PJxXav027688;
Fri, 25 Apr 2014 15:59:33 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com
(8.14.7/8.14.7/Submit) id s3PJxXdj027687; Fri, 25 Apr 2014 15:59:33 -0400
Date: Fri, 25 Apr 2014 15:59:33 -0400
Message-Id: <201404251959.s3PJxXdj027687@hobgoblin.ariadne.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: draft-ietf-salud-alert-info-urns@tools.ietf.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net;
s=q20140121; t=1398455975; bh=7p8xazRAYezfgjsJi2iEjr5ZGPbemuLt51rSBJ1/IeY=;
h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject;
b=AolG2LOMaq6+FQFIC1E2HQGEn5gBU91x7L0VQyIb2WnPdlMLydQhzoR0/XJe5OOIs
+i13QSCkK1dB2ggcuGMUsdNh6PMFWLmg7Yniy7KT5FLnet3QjGhjqhLDbIKGR/QvzA
9QutQraDBno5A1K9duv0hHb710DfCKcGcMHlb8U9en3lddkUyxz40JnrSmCCQzLiXS
mmlSYatAMq2zmXNt2lkckOJBUlbVqdxM0Y3OWLIGKLVemYpEmByLSQuk+5IuPPD5PQ
cvDboAyEqLa59hFWLADd2O9W0E+J8pfTp6K3Ct9z5goNdyCDhWawsefRvewi63IVL7
CRZlH77MW+2KQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/asvPgB3O2Xh260sYpj0CbEVtjIM
Cc: salud@ietf.org
Subject: [salud] Reply to Pearl Liang (IANA)
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list
<salud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/salud>,
<mailto:salud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/salud/>
List-Post: <mailto:salud@ietf.org>
List-Help: <mailto:salud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/salud>,
<mailto:salud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Apr 2014 19:59:44 -0000
[as an author] I have reformatted and somewhat revised my proposed response to IANA. The authors generally seem to agree with my response; I want to provide the final draft of the message to verify our agreement and solicit any improvements you have. If I don't hear otherwise, I will send this on Wednesday morning. Dale ---------------------------------------------------------------------- From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: drafts-lastcall@iana.org Subject: [IANA #755327] Last Call: <draft-ietf-salud-alert-info-urns-12.txt> (URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)) to Proposed Standard CC: salud-chairs@tools.ietf.org, draft-ietf-salud-alert-info-urns@tools.ietf.org --text follows this line-- > IANA understands that, upon approval of this document, there are two > actions which IANA must complete. This is correct. > First, in the Formal URN Namespaces subregistry of the Uniform > Resource Names (URN) Namespaces registry located at: > > http://www.iana.org/assignments/urn-namespaces/ > > a new URN will be registered as follows: > > URN Namespace: alert > Reference: [ RFC-to-be ] This is correct. > Second, a new registry called the Alert URN Identifiers registry is > to be created. This is correct. > New URNs in the Alert URN Identifiers Registry are created through > Standards Action as defined by RFC 5226. The process is more complex than that; the details are in section 9.1 of the RFC: The policy for adding a new standard <alert-category> is 'Standards Action'. The policy for adding <alert-identifiers>s or patterns of <alert-identifiers>s within a particular <alert-category> may differ for each <alert-category>and MUST be defined by the document defining the corresponding <alert-category>. That is: New "alert-categories" (items that do not contain a colon) are created by Standards Action. The policy for new "alert-identifiers" (items containing a colon) is set by the alert-category that it starts with. All existing alert-categories specify the policy Standards Action for adding alert-identifiers. The update policy for any alert-category will be stated in the RFC that defines it, so the "Reference" column implicitly specifies the update policy for that alert-category. Perhaps it would help to add a column "update policy" to this registry, which for each alert-category will contain the updating policy for alert-identifiers in that alert-category. (This column would be empty for alert-identifiers.) Or perhaps this registry should be divided into two registries, one for alert-categories (listing an update policy for the related alert-identifiers) and a second registry for the alert-identifiers (without an update policy column). What does IANA recommend for organizing this information? > QUESTIONs: > Should this new registry a sub-registry of the registry > 'Service URN Labels' located at > http://www.iana.org/assignments/urn-serviceid-labels? Or is this new > registry 'Alert URN Identifiers' a stand-alone with a brand new URL? > > Then, if the latter, what should be the name of the master "Parameter" > registry? Is Uniform Resource Names (URN)? See iana.org/protocols for > a list of main registry pages and the registries they include. The new registry will be a new registry named "Alert URN Identifiers" under the protocol name "Uniform Resource Names (URN)", and thus will be alongside "URN Service Labels", not a sub-registry of it. > IANA understands that the initial registrations in this new registry > are to be collected from section 9.2.1 through 9.2.6 of the current > document. IANA understands that the initial registry will look like > this: > > <alert-category>/ Reference Description > <alert-identifier> > -------------------------------------------------------------------------- > service [ RFC-to-be ] Specific telephony > service used in this > call > service:normal [ RFC-to-be ] Normal ring/ringback > rendering (default value) > service:call-waiting [ RFC-to-be ] Call waiting was > initiated at the other side > of the call > service:forward [ RFC-to-be ] Call has been forwarded > service:recall:callback [ RFC-to-be ] Recall due to callback > service:recall:hold [ RFC-to-be ] Recall due to call hold > service:recall:transfer [ RFC-to-be ] Recall due to transfer > source [ RFC-to-be ] Classification > of the other party > to the call > source:unclassified [ RFC-to-be ] Unclassified ring/ringback > rendering (default value) > source:internal [ RFC-to-be ] User at the other side of > the call is internal to the > enterprise or PBX system > source:external [ RFC-to-be ] User at the other side of > the call is external to the > enterprise or PBX system > source:friend [ RFC-to-be ] User at the other side of > the call is a friend > source:family [ RFC-to-be ] User at the other side of > the call is a family member > priority [ RFC-to-be ] Priority of the > call > priority:normal [ RFC-to-be ] Normal ring/ringback > rendering (default value) > priority:low [ RFC-to-be ] Low priority call. > priority:high [ RFC-to-be ] High priority call > duration [ RFC-to-be ] Duration of alerting signal > alerting signal > duration:normal [ RFC-to-be ] Normal ring/ringback > rendering (default value) > duration:short [ RFC-to-be ] Shorter than normal > duration:long [ RFC-to-be ] Longer than normal > delay [ RFC-to-be ] Delay of rendering of alerting > of alerting signal > delay:none [ RFC-to-be ] Immediate alerting > (default value) > delay:yes [ RFC-to-be ] Delayed alerting > locale [ RFC-to-be ] Location-specific > alerting signals > locale:default [ RFC-to-be ] Alerting not location > specific > (default value) > locale:country:<ISO 3166-1 country code> > [ RFC-to-be ] Alerting according to the > conventions of the specified > country > > IANA understands that these two actions are the only ones that need > to be completed upon approval of this document. The list of initial registrations in your e-mail is correct (allowing for the irregular use of line breaks in the original e-mail). That is, it is correct in regard to the data items to be recorded; the proposed registry may be organized differently if IANA recommends doing so (as discussed above). Dale, for the authors of ietf-salud-alert-info-urns ---------------------------------------------------------------------- [EOF]
- [salud] Reply to Pearl Liang (IANA) Dale R. Worley
- Re: [salud] Reply to Pearl Liang (IANA) Paul Kyzivat
- [salud] The registry structure (was: Reply to Pea… Dale R. Worley
- Re: [salud] The registry structure Paul Kyzivat
- Re: [salud] The registry structure Dale R. Worley
- Re: [salud] Revised reply to Pearl Liang (IANA) Dale R. Worley