[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltru] sgn-tags with regions (was: Re: draft updated)



Kent Karlsson <kent dot karlsson14 at comhem dot se> wrote:

Admittedly this was a bit more plausible in 2001, when we were still fooling ourselves that there was no generative mechanism and tags were completely atomic.

The <language code>-<region code> tags have been generative since RFC 1766.

Both 1766 and 3066 do say this about the language-region combinations. My comment was based largely on the remarks of Harald Alvestrand (of course the author of 1766 and 3066), back in June 2004 when we were planning to extend the generative mechanism beyond languages and regions:

"I think subtag registration is an approach that is harder to manage and less useful to the wide communtiy than a whole-tag registration scheme, and I think that generative grammars that permit 'all well-formed tags' is less useful than a scheme that permits only tags that someone has bothered to argue are useful. But I have been convinced by the debate on the ietf-languages list that a) I'm in a minority on this, and b) there are reasonable arguments for switching to a generative scheme."

RFC 1766 actually went farther than this in declaring tags, even the language-region combinations, to be atomic:

"Applications should always treat language tags as a single token; the division into main tag and subtags is an administrative mechanism, not a navigation aid."

And both RFC 1766 and RFC 3066 say (without exception!) that the two-letter second subtags are region subtags (here the 1766 formulation; slighly expanded, but still no exeptions, in RFC 3066):

|    -    All 2-letter codes are interpreted as ISO 3166 alpha-2
|         country codes denoting the area in which the language is
|         used.

This is true as far as it applied to generative tags. The problem was that RFC 3066 introduced the "additional information" registration model, specifically to sanction the sign-language tagging mechanism that actually changed the definition of the tags somewhat:

"This [registration] procedure MAY also be used to register information with the IANA about a tag defined by this document, for instance if one wishes to make publicly available a reference to the definition for a language such as sgn-US (American Sign Language)."

Although the second subtag in each of the registered sgn-tags was in fact an ISO 3166 alpha-2 country code, it was meant to identify the language, not necessarily its region of use. Not only is ASL used outside the United States, as John pointed out, but the tag "sgn-US" applies equally to ASL in the U.S. or anywhere else. This is not the usual purpose of region subtags; while they are not expected to be laser-precise in pinpointing geographic usage, they are meant to show regional differences:

"But on forty-three minutes, United were level."  (actual en-GB quote)
"But with two minutes to go in the half, Manchester United tied it up." (translation into en-US)

I see that as implying that there is an implicit "as used in the US" part of the description of "sgn-US", even though that is not part of the description for "sgn-US" in the registry. (Etc. for the other sgn-* grandfathered tags.)

We don't have to guess at this; we could simply ask Michael what his intent was for the denotation of these tags.

I'm basing my interpretation on the Description fields in the Language Subtag Registry, which were copied from the RFC 3066 registration records, and on the table at evertype.com which lists the registered sgn-tags as well as many others which were never proposed, and on my recollection from the discussions on ietf-languages in 2001.

--
Doug Ewell  *  Arvada, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.