Re: [salud] Updates to section 6

[Laura Liess <[e-mail]>]

Paul,


>
> I presume you mean urn:alert:locale:[e-mail]"?
>

  I didn't meant "bar" being part of the <provider-id>, I just meant  foo
and bar being the <alert-label>s  of a German country-specific tone and
using the country code top level domain "de" as a <provider-id>, but it's
true, I don't know who could be the owner.

However, in this specification we don't define or register any particular
national tone, we expect national companies or organisations and national
standardization bodies to do it. We could require anybody who defines
national tones to be owner of a subdomain of the respective country code
top level domain which he must use as <provider-id> for the tone. In many
cases, national tones are defined by big phone companies anyway.

But I don't know, maybe this doesn't work at all and it was just a bad
idea.  Then let's forget it.

Thank you
Laura



>
> I see several problems with that:
>
> - there is no .bar TLD. :-)
>   perhaps you meant: [e-mail] ??
>   The existence of country-specific TLDs could be exploited.
>
> - but then each country-specific private name would require an owner.
>   We aren't in a position to become the owner for all of those,
>   and I don't know how we could recruit anyone to do it.
>
> - then they would all be private names. Where would they be
>   specified?
>
> I think we just need to fiddle with the words to deal with this.
>
>         Thanks,
>         Paul
>
>  Laura
>>
>>
>> 2013/3/28 Paul Kyzivat <[e-mail]
>> <mailto:[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] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/_**_listinfo/salud<https://www.ietf.org/mailman/__listinfo/salud>
>>     <https://www.ietf.org/mailman/**listinfo/salud<https://www.ietf.org/mailman/listinfo/salud>
>> >
>>
>>
>>
>>
>>
>> ______________________________**_________________
>> salud mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/**listinfo/salud<https://www.ietf.org/mailman/listinfo/salud>
>>
>>
> ______________________________**_________________
> salud mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/salud<https://www.ietf.org/mailman/listinfo/salud>
>