[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 []) 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 ([]) by localhost (ietfa.amsl.com []) (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 ([]) by qmta04.westchester.pa.mail.comcast.net with comcast id uCiA1n0051GhbT854Kzbdj; Fri, 25 Apr 2014 19:59:35 +0000
Received: from hobgoblin.ariadne.com ([]) 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 []) 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.

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,
--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?

> 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