Re: [salud] Updates to section 6

[Laura Liess <[e-mail]>]

The  "locale:country:<ISO 3166-1 country code> " seems to be some kind of
different and difficult.

Now that we have the "private-name " stuff working fine, why not use it for
country specific tones? Instead of "urn:alert:locale:country:de:foo:bar"
    we would have "urn:alert:foo@de:bar".   Or is something wrong with it?

Laura


2013/3/28 Paul Kyzivat <[e-mail]>

> Hi Dale,
>
> Comments inline.
>
>
> On 3/28/13 8:39 AM, Dale R. Worley wrote:
>
>> I suggest the following edits to section 6 to clarify the registration
>> process and to align the syntax terminology with the new ABNF.  The
>> changes are marked in the left margin with "-" and "+".
>>
>> I have a number of questions and comments at the beginning of this
>> text.
>>
>> Comments?
>>
>> Dale
>> ------------------------------**------------------------------**
>> ----------
>> --- 07-section-6        2013-03-27 20:09:39.713133697 -0400
>> +++ 07-updated-section-6        2013-03-27 20:35:12.872213564 -0400
>> @@ -1,224 +1,250 @@
>> +[[ Where did this rule come from?
>> +     Each <alert-category> or <alert-indication> label MUST NOT exceed 27
>> +     characters.
>> +   Can/should we maintain this rule given that we allow punycode labels
>> +   in FQDNs?
>> +   (I have a memory that there is a restriction on host name labels to
>> +   be no longer than 27 characters, but I could not find that stated
>> +   in any RFC.)
>>
>
> I don't know. I see no reason to keep it.
>
>
>  +I've removed "and the rules to combine them [i.e., <alert-label>s]"
>> +from the description at the beginning of section 6.1 because for
>> +registered URNs, the only rule needed is "use only the combinations
>> +listed in the registry".
>>
>
> OK.
>
>
>  +We say "The policy for adding <alert-indication>s may differ for each
>> +<alert-category> and MUST be defined by the document describing the
>> +corresponding <alert-category>."  But we do not state the policy for
>> +the standard <alert-category>s.  And I do not remember what we decided
>> +that policy should be.
>>
>
> Note I commented on a related issue re "local" below. *That* category
> needs a different rule from all the others, in that subordinates to
> "local:country" may not be registered via the iana process. But I suppose
> alternatives to default and country may be added as in any other.
>
> Otherwise I suggest we just specify that adding <alert-indication>s
> subordinate to any of the <alert-category>s defined in *this* document is
> Standards Action.
>
> Or we could take the easy way out and simply say that its Standards Action
> for everything. (Except for private ones of course.)
>
>
>  +I've removed the entries like this:
>> +
>> +   service:<private-name>         RFC XXXX  Reserved for private
>> +                                            extensions
>> +
>> +because they are not enabled by the registration process, but rather
>> +by the extension rules of section 7.
>>
>
> OK
>
> [snip]
>
>
>    6.2.6.  The "locale"  alert-category and alert-identifiers
>>
>>      The following table contains the initial IANA registration for the
>>      "locale" <alert-category> and <alert-identifier>s.  The value of this
>> -   indicator provides information about the location of the user at the
>> -   other side of the call.
>> +   indicator provides information suggests that alerting signals
>> +   characteristic of the specified location should be used.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>   Liess, et al.             Expires April 5, 2013                [Page 21]
>>
>>   Internet-Draft               Alert-Info URNs                October 2012
>>
>>
>> - <alert-category>/             Reference  Description
>> + <alert-category> or           Reference  Description
>>    <alert-identifier>
>>    ------------------------------**-----------------------------
>>    locale                        RFC XXXX  <alert-category>
>>                                            for "locale" <alert-identifier>
>>    locale:default                RFC XXXX  Alerting not location
>>                                            specific
>>                                            (default value)
>>    locale:country:<ISO 3166-1 country code>
>>                                  RFC XXXX  Country-specific alerting
>> - locale:<private-name>         RFC XXXX  Reserved for private
>> -                                         extensions
>> ------------------------------**------------------------------**
>> ----------
>>
>
> I'm wondering about the registration for country codes. I don't know if it
> is clear here what IANA should do. Does this mean:
>
> - IANA should go out and get a copy of the ISO 3166-1 list and populate it
> into their own table?
>
> - Specific country codes must be registered by some specification, but
> must conform to 3166-1?
>
> Clearly we *intend* that individual country codes will not be listed in
> the IANA table, but rather are implicitly included by reference. How do we
> say that?
>
>         Thanks,
>         Paul
>
>
> ______________________________**_________________
> salud mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/salud<https://www.ietf.org/mailman/listinfo/salud>
>