[salud] (no subject)

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

([e-mail])
Subject: Re: [salud] Updates to section 6
References: <[e-mail]>
<[e-mail]> <[e-mail]>
--text follows this line--
[as an individual]

> From: 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?

E.g., <urn:alert:service:call-waiting@de>

That is an interesting idea.  But we have a lot of apparatus regarding
<private-name>s, so we would either need to make an exception for
domains that contained only one label, or to designate some
organization that is responsible for each country-TLD.

> From: Laura Liess <[e-mail]>
> 
> 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.

Fortunately, the "locale" URNs don't describe sensory aspects of
signals but semantic ones.  So while <urn:locale:country:de> indicates
that the signal should be rendered using German conventions, each
device interprets those conventions separately.

In practice, I don't think the "locale" URNs will get a great deal of
use, because in many cases one UA will not know if another UA
implements any particular "locale" URN.

Dale