Re: [salud] The registry structure

[Paul Kyzivat <[e-mail]>]

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 <[e-mail]>
>
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/salud
>