Subject: Re: [salud] The registry structure

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 May 2014 12:58:01 -0400

I agree with your proposal, except that the names of the tables are 
quite cumbersome. How about:

s/Alert URN Identifiers alert-categories/Alert URN alert-categories/
s/Alert URN Identifiers alert-identifiers/Alert URN alert-identifiers/

	Thanks,
	Paul

On 4/30/14 6:09 PM, Dale R. Worley wrote:
> [as an author]
>
>> From: Paul Kyzivat <[email-masked]>
>
>> My only comment is that it is probably better that we decide what we
>> want the registry to look like than to let iana do it for us.
>
> I am looking at the following pages for examples:
> the "Uniform Resource Names (URN)" section of http://www.iana.org/protocols
> the "Service URN Labels" page,
> http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels.xhtml
> the "Sieve Extensions" page,
> http://www.iana.org/assignments/sieve-extensions/sieve-extensions.xhtml
> (because it has complicated registration procedures).
>
> It seems to me that we want "Alert URN Identifiers" to be an item
> under "Uniform Resource Names (URN)", and we want it to point to a
> separate web page, as "Service URN Labels" does.
>
> How do we want to handle the registration procedures specification?
> IANA wants to know this and probably needs to know it.
>
> Most tables give the registration procedures in the header of the
> table.  E.g.,
>
>      URN Service Labels
>
>      Registration Procedure(s)
> 	Standards Action
>
>      Reference
> 	[RFC5031]
>
> But the Sieve table has a separate table that gives registration
> procedures:
>
>      Range                                 Registration Procedures
>      -----                                 -----------------------
>      vendor-controlled                     First Come First Served
>          (name begins with "vnd.")
>      IETF-controlled (no "vnd." prefix)    Standards track or
>                                            IESG-approved experimental RFC
>
> It would be simpler if there was one combined table, but it would be
> difficult to find a place to specify that alert-categories require
> standards action.
>
> Perhaps we should separate the alert-categories into a separate table:
>
>      Alert URN Identifiers alert-categories
>
>      Registration Procedure(s)
> 	Standards Action
>
>      Reference
> 	[RFCxxxx]
>
>      Name       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
>
> and then
>
>      Alert URN Identifiers alert-identifiers
>
>      Registration Procedure(s)
> 	As specified in the corresponding alert-category
>
>      Reference
> 	[RFCxxxx]
>
>      Name              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
>      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
>
> What do people think?
>
> Dale
>
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 2 May 2014 18:25:31 -0400

> s/Alert URN Identifiers alert-identifiers/Alert URN alert-identifiers/

I agree.  The draft uses the term

    "alert" URN

in dozens of places.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 6 May 2014 14:15:03 -0400

[as an author]

Trying to close out the remaining work, I ran into the fact that I
haven't sent a reply to IANA yet.  This is a revised version, based on
Paul's observation that it would be wise for us to decide on the
registry structure ourselves.  I've incorporated a two-registry
structure, one for alert-categories and one for alert-identifiers.
Looking at the new structure when written down, I think it is
considerably clearer than a one-registry structure.

Please look it over to see if there is anything that is wrong or
unclear.

Dale
----------------------------------------------------------------------
From: [email-masked] (Dale R. Worley)
Sender: [email-masked] (Dale R. Worley)
To: [email-masked]
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: [email-masked],
        [email-masked],
	[email-masked]
--text follows this line--
> (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:

   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 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 a sub-registry 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

    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

    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.

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

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