[salud] Reply to Pearl Liang (IANA)

[[e-mail] (Dale R. Worley)]

[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: [e-mail] (Dale R. Worley)
Sender: [e-mail] (Dale R. Worley)
To: [e-mail]
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: [e-mail],
        [e-mail]
--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]