Subject: [Ltru] Bihari and Himachali (was: Re: Editor's copy of draft-4645bis-06)

From: "Doug Ewell" <[email-masked]>
Date: Thu, 26 Jun 2008 18:34:47 -0600

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

> Even if that interpretation of "Himachali" and "Bihari" is true (which 
> I doubt a bit, they look like inflections rather than composite words; 
> I guess "Bihari people" (http://en.wikipedia.org/wiki/Bihari_people) 
> does not mean "Bihar languages people"...),

It almost certainly is an inflection or particle of some sort.

> that does not prevent the expressions "Himachal languages" and  "Bihar 
> languages" which conforms to the 639-2 rule (for good or bad)...

If there is a "639-2 rule," it is that 639-2 associates names with code 
elements in whatever way they see fit.  The names "Bihari" and 
"Himachali" came from 639-2; I assume they are following their own 
rules, if any.

Perhaps you meant the 639-5 rule, whereby 639-5 applies a standard 
template of "X languages" to most collection codes (but not all; see 
"Armenian (family)", for instance) and converts remainder codes to full 
group codes in the process.  We in LTRU regard the 639-5 names and 
denotations as superseding those of 639-2, for purposes of the LSR.  But 
these two codes are not in 639-5, so we have no 639-5 name or denotation 
to go by; we are stuck with what 639-2 gave us.

In an environment where we are so rigid about adhering to the precise 
ISO 639 names that we will have to carry both "Macedo Romanian" and 
"Macedo-Romanian" as separate Description fields, and where I felt I had 
to ask the group to recapitalize "Sign languages", I don't think you 
will get much support for adding the word "languages" to these two ISO 
639 names.

--
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
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 26 Jun 2008 19:55:57 -0600

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

>>> The subtag 'ase' will replace "sgn-US" as the (sub)tag meaning 
>>> "American Sign Language". You can then use region subtags with it as 
>>> needed. E.g. ase-US or sgn-ase-US (based on the current draft).
>
> I still say that it is not even a possible interpretation of RFC 3066 
> to remove the region code in these cases, no matter how the sgn-* tags 
> were discussed at registration time.

You are wrong.  Sorry to be so discourteously direct, but let facts be 
submitted to a candid world.

> The "US" part in "sgn-US" is and remains a region code, and the 
> appropriate target code (for Preferred-Value of the to-be-deprecated 
> tag sgn-US) should be "asl-US".

The "US" part is there to modify and narrow down "sgn", to show that it 
means not merely "sign languages" but specifically "American Sign 
Language."  It is NOT functioning as a true region code.  It is actually 
functioning just like an extlang, although that concept had not yet been 
formalized in 2001.  Forget about the syntactic point that "US" is two 
letters long, and focus on the parallel semantic relationships:

"zh" means "Chinese."
"zh-yue" means "not just any Chinese, but specifically Cantonese."

"sgn" means "sign languages."
"sgn-US" (as registered) means "not just any sign language, but 
specifically ASL."

These tags, registered by ietf-languages in 2001, used two-letter ISO 
3166 codes in an extremely loose sense of the term "region 
identification."  They don't refer to regional variations of a single 
language, as is the case for normal generative tags; rather, they refer 
to *completely different languages*.  This is the change in semantics 
that Peter Constable was referring to.

By arguing that the Preferred-Value for "sgn-US" should be "asl-US", you 
are arguing that the "US" in "sgn-US" actually modifies "sgn" in TWO 
ways:

1. to indicate "American Sign Language"
2. to indicate the region "United States"

which is a position I find completely untenable.

Consider the special rule added to RFC 3066, Section 3, that attempted 
to lend legitimacy to these tags:

"This 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)."

Notice that this is phrased in terms of making a reference publicly 
available, not changing the definition of "a tag defined by this 
document" from its generative meaning to something else, but in fact it 
does change the meaning.  I know you understand this, because you do not 
claim that "sgn-US" as registered means "any old sign language as used 
in the United States," which would be its generative meaning.

Notice, too, that this rule has never been invoked for ANY other 
language -- no matter how well-known and exhaustively documented, no 
matter how obscure and in need of documentation -- except for the batch 
of sign languages registered in 2001, shortly after RFC 3066 was 
published.  And notice that this rule no longer exists in RFC 4646, or 
in draft-4646bis.  It was only in RFC 3066 BECAUSE of this batch of tags 
that were coming down the pike, that DID use two-letter ISO 3166-based 
second-position subtags to mean something OTHER than "as used in 
such-and-so country."

You are right in thinking that "xxx-US" for some language 'xxx' SHOULD 
mean "language xxx as used in the United States."  In all *generative* 
tags going back to RFC 1766, that is exactly what they mean, no 
exceptions.  That is exactly why Peter and I and I'm sure others dislike 
these nonstandard sign-language tags so much, and can't wait to replace 
them with generative tags that mean just what they say.

You can choose not to believe the Description field in the Registry, nor 
the original registration form from 2001 which is still archived by IANA 
(http://www.iana.org/assignments/lang-tags/sgn-US), and you can choose 
not to take into account the intent of the requester, but the fact 
remains that the "US" in "sgn-US" is NOT serving double duty as both a 
de-facto extlang AND a region qualifier.  No subtag has ever been asked 
to serve double duty like that.

I am cc'ing Michael, the original requester, again in hopes that he will 
have something definitive to say, because evidently what Peter and 
Addison and I are saying is not definitive enough.

> "asl-CA" (e.g.) is simply not covered with tags in the current LSR, 
> along with 100+ other sign languages (plus regional variants of those 
> sign languages) that will be taggable using 639-3 codes.

This part, at least, is true.

---

From: Michael Everson <[email-masked]>
Date: Fri, 27 Jun 2008 09:30:14 +0100

What Doug says is definitive and correct.

At 19:55 -0600 2008-06-26, Doug Ewell wrote:
>>>>The subtag 'ase' will replace "sgn-US" as the 
>>>>(sub)tag meaning "American Sign Language". 
>>>>You can then use region subtags with it as 
>>I still say that it is not even a possible 
>>interpretation of RFC 3066 to remove the region 
>>code in these cases, no matter how the sgn-* 
>>tags were discussed at registration time.
>
>You are wrong.  Sorry to be so discourteously 
>direct, but let facts be submitted to a candid 
>world.
>
>>The "US" part in "sgn-US" is and remains a 
>>region code, and the appropriate target code 
>>(for Preferred-Value of the to-be-deprecated 
>The "US" part is there to modify and narrow down 
>"sgn", to show that it means not merely "sign 
>languages" but specifically "American Sign 
>Language."  It is NOT functioning as a true 
>region code.  It is actually functioning just 
>like an extlang, although that concept had not 
>yet been formalized in 2001.  Forget about the 
>syntactic point that "US" is two letters long, 
>and focus on the parallel semantic relationships:
>
>"zh" means "Chinese."
>"sgn-US" (as registered) means "not just any 
>sign language, but specifically ASL."
>
>These tags, registered by ietf-languages in 
>2001, used two-letter ISO 3166 codes in an 
>extremely loose sense of the term "region 
>identification."  They don't refer to regional 
>variations of a single language, as is the case 
>for normal generative tags; rather, they refer 
>to *completely different languages*.  This is 
>the change in semantics that Peter Constable was 
>referring to.
>
>By arguing that the Preferred-Value for "sgn-US" 
>should be "asl-US", you are arguing that the 
>"US" in "sgn-US" actually modifies "sgn" in TWO 
>ways:
>
>Consider the special rule added to RFC 3066, 
>Section 3, that attempted to lend legitimacy to 
>these tags:
>
>"This 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)."
>
>Notice that this is phrased in terms of making a 
>reference publicly available, not changing the 
>definition of "a tag defined by this document" 
>from its generative meaning to something else, 
>but in fact it does change the meaning.  I know 
>you understand this, because you do not claim 
>that "sgn-US" as registered means "any old sign 
>language as used in the United States," which 
>would be its generative meaning.
>
>Notice, too, that this rule has never been 
>invoked for ANY other language -- no matter how 
>well-known and exhaustively documented, no 
>matter how obscure and in need of documentation 
>-- except for the batch of sign languages 
>registered in 2001, shortly after RFC 3066 was 
>published.  And notice that this rule no longer 
>exists in RFC 4646, or in draft-4646bis.  It was 
>only in RFC 3066 BECAUSE of this batch of tags 
>that were coming down the pike, that DID use 
>two-letter ISO 3166-based second-position 
>subtags to mean something OTHER than "as used in 
>such-and-so country."
>
>You are right in thinking that "xxx-US" for some 
>language 'xxx' SHOULD mean "language xxx as used 
>in the United States."  In all *generative* tags 
>going back to RFC 1766, that is exactly what 
>they mean, no exceptions.  That is exactly why 
>Peter and I and I'm sure others dislike these 
>nonstandard sign-language tags so much, and 
>can't wait to replace them with generative tags 
>that mean just what they say.
>
>You can choose not to believe the Description 
>field in the Registry, nor the original 
>registration form from 2001 which is still 
>archived by IANA 
>(http://www.iana.org/assignments/lang-tags/sgn-US), 
>and you can choose not to take into account the 
>intent of the requester, but the fact remains 
>that the "US" in "sgn-US" is NOT serving double 
>duty as both a de-facto extlang AND a region 
>qualifier.  No subtag has ever been asked to 
>serve double duty like that.
>
>I am cc'ing Michael, the original requester, 
>again in hopes that he will have something 
>definitive to say, because evidently what Peter 
>and Addison and I are saying is not definitive 
>enough.
>
>>"asl-CA" (e.g.) is simply not covered with tags 
>>in the current LSR, along with 100+ other sign 
>>languages (plus regional variants of those sign 
>>languages) that will be taggable using 639-3 
>>codes.
>
>http://www.alvestrand.no/mailman/listinfo/ietf-languages  –

-- 
Michael Everson * http://www.evertype.com
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru