[salud] [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

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

> (BEGIN IANA LAST CALL COMMENTS)
> 
> IESG/Authors/WG Chairs:
> 
> IANA has reviewed draft-ietf-salud-alert-info-urns-12.  Authors
> should review the comments and/or questions below.  Please report any
> inaccuracies and respond to any questions as soon as possible.
> 
> IANA understands that, upon approval of this document, there are two
> actions which IANA must complete.

This has been revised to three actions:  adding a row to "Formal URN
Namespaces" and creating two new registries, as described below.

> 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.

Two new registries are to be created, as described below.

> New URNs in the Alert URN Identifiers Registry are created through
> Standards Action as defined by RFC 5226.

That is not correct.  The process is more complex than that; the
details are in section 9.1 of the RFC-to-be:

   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 a new
"alert-identifier" (an item 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 registration policy for any alert-category will be stated in the
RFC that defines it, so the "Reference" column for that alert-category
implicitly specifies the registration policy for that alert-category.

> 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. 

After discussing this with the authors, we believe that the required
information can be best recorded with two registries, one named "Alert
URN alert-categories" for the items that are alert-categories (the
items without colons) and one named "Alert URN alert-identifiers" (the
items with colons).  Both registries will be under the protocol name
"Uniform Resource Names (URN)", and thus will be alongside "URN
Service Labels", not sub-registries of it.

The two registries are connected by the fact that the registration
procedure for an alert-identifier is controlled by the corresponding
entry in the alert-category registry.  This is somewhat like the
"Range/Registration Procedures" table in the Sieve Extensions
registry.

The registries would look like this:

    Alert URN alert-categories

    Registration Procedure(s)
	Standards Action

    Reference
	[RFCxxxx]

    alert-category   Description           Reference   Registration Procedure(s)
					               for alert-identifiers
    --------------   -----------           ---------   -------------------------
    service          Specific telephony    [RFCxxxx]   Standards Action
                     service used in this
		     call
    source           Classification of the [RFCxxxx]   Standards Action
                     other party to the 
		     call
    [etc.]

and

    Alert URN alert-identifiers

    Registration Procedure(s)
	As specified by the corresponding alert-category

    Reference
	[RFCxxxx]

    alert-identifier  Description                                     Reference
    ----------------  -----------                                     ---------
    service:normal    Normal ring/ringback rendering (default value)  [RFCxxxx]
    service:call-waiting                                              [RFCxxxx]
                      Call waiting was initiated at the other side
                      of the call
    [etc.]
    source:unclassified	                                              [RFCxxxx]
                      Unclassified ring/ringback rendering (default
	              value)
    source:internal   User at the other side of the call is internal  [RFCxxxx]
                      to the enterprise or PBX system
    [etc.]

The authors believe that a two-registry structure allows the
registration procedures to be specified more clearly than a
one-registry structure.

> 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).  The
alert-category entries are to be placed in one registry and the
alert-identifier entries are to be placed in the other registry, as
described above.

Thanks,

Dale, for the authors of ietf-salud-alert-info-urns