Re: Proposed resolution for Issue 13 (language tags)

Frank Ellermann wrote:
> Julian Reschke wrote:
> 
>> language-tag  = <Language-Tag, defined in [RFC4646], Section 2.1>
> 
> +1, but keep in mind that LTRU might replace 4646 by 4646bis before
>     2616bis is ready.

Optimally, we'll just have to bump up the reference then, right?

>> Example tags include:
> 
> RFC 2616 has:  en, en-US, en-cockney, i-cherokee, x-pig-latin
> 
> Please replace en-cockney by say es-419, and i-cherokee by say
> az-Arab.  Rationale:  
> 
> * en-cockney doesn't exist,
> * es-419 shows a new 4646-feature (UN region number),
> * i-cherokee doesn't exist,
> * az-Arab shows a new 4646-feature (script subtags).

Ack.

>> (The last three tags above are not registered tags; all but the
>>  last are examples of tags which could be registered in future.)
> 
> That misses the point of RFC 4646, apart from some grandfathered
> tags, and primary subtags like "en" that can be used as tags, the
> registry conains *subtags*.  
> 
> And "en", "US", "es", "419", "az", and "Arab" are all registered
> *subtags*. 

I'm tempted to drop the statement, or even go further to drop the 
example as well.

>> ...feedback appreciated.
> 
> I missed that above, the link is wrong:
> 
> | The name space of language tags is administered by the
> | IANA (<http://www.iana.org/assignments/language-tags>).
> 
> That is the *obsolete* RFC 3066 tag registry, please write:
> 
> | The name spaces of language subtags are administered by the
> | IANA, <http://www.iana.org/assignments/language-subtag-registry>.

Ack.

> Actually three namespaces (languages, scripts, regions) in
> essence copy standards by third parties, but these details
> are explained in RFC 4646.
> 
>  Frank


BR, Julian