Subject: Re: [Ltru] UNGEGN definitions and UNICODe Glossary of terms

From: "Doug Ewell" <[email-masked]>
Date: Tue, 7 Oct 2008 21:42:19 -0600

John Cowan <cowan at ccil dot org> wrote one of those responses that 
makes me wish I could write that well.  Clumsily worded addenda follow.

> We expect in fact that ISO 639-1 is a closed set; that no new 2-letter 
> codes will be created.  An exception would be if a new language were 
> to be added to 639-1, 639-2, and 639-3 simultaneously: this would be a 
> language obscure enough to be missed by 639-3, and well-known enough 
> to require a 639-1 entry.  The only scenario I can foresee requiring 
> such an action is if dialect drift has been large enough over a long 
> enough time (probably centuries) that it becomes the scientific 
> consensus that English or French or Spanish has broken apart into two 
> or more distinct languages.

I do worry that the MA will bow to political pressure and register 
"Macedonian" in this way, just as was done with "Serbian" and "Croatian" 
and "Bosnian."  I hope my worries are unfounded.

>> -(iii) On page 22, inside "3.1.1. File Format", the last phrase 
>> describing the representation "2004-06-28" in the Gregorian calendar 
>> is a direct application of the standard ISO 8601:2004Data elements 
>> and interchange formats-Information interchange-Representation of 
>> dates and times, third edition", 2004 that should be mentionned 
>> inside "9.1 Normative references".
>
> The normative reference is to RFC 3339, which is a profile of ISO 
> 8601.  It is not necessary to understand ISO 8601 to understand RFC 
> 3339.

In fact, in theory we could probably say "in year-month-day format, 
separated by hyphens" and be done with it.  There shouldn't be any IPR 
on the format.

Using RFCs as references to other RFCs is often a cleaner solution than 
using equivalent ISO standards, because of the guarantee that the entire 
spec is freely available (as in both speech and beer).  And for our 
*very* limited purposes, RFC 3339 is equivalent to ISO 8601.

>> -(ix) On page 66, inside"4.6. Considerations for Private Use Subtag", 
>> the paragraph concerning user-reserved ISO 3166-1 alpha-2 code 
>> elements should be enriched by adding that "Article 8.2.of ISO 3166-1 
>> considers essential that all user should notify to ISO 3166/MA every 
>> occurrence of their intentions concerning user-assigned code 
>> elements, so as to coordinate such uses and to avoid that two 
>> differents alpha-2 code elements be choosen by two different users 
>> for the same "country name" in the same domain of use.
>>
>> For example, there is today no entry and no reserved code element 
>> inside ISO 3166-1 concerning the country name "KOSOVO". But, as the 
>> European Union notified the use of the user-reserved alpha-2 code 
>> element "XK", ISO 3166/MA is stongly recommanding to use "XK" when 
>> representation of the country name "KOSOVO" is needed.
>
> As a matter of implicit policy we abstain from such statements about 
> private-use codes.  They who use them in interchange do so entirely at 
> their own risk.

I don't think there's any real harm in reminding people who want to 
create subtags in the private-use space that the MA wants to know what 
code elements they chose.

I do, however, agree that we should not echo back the MA's "strong 
recommendations," as users have a tendency to equate those with formally 
assigned code elements (which is kind of how we got involved with 
"exceptionally reserved" code elements).

>> I would also advocate for the addition of ISO 3166-2 :2007. Codes for 
>> the representation of names of countries and their subdivisions--Part 
>> 2: Country subdivision code", December 2007.
>
> 3166-2 codes are not used in BCP 47.  A normative reference implies 
> that understanding of the referent is needed to understand BCP 47 
> fully, which is not the case for 3166-2.

It should not even be an informative reference, since neither BCP 47 nor 
the Registry mentions informatively, or even alludes to, ISO 3166-2.

For reasons that have been outlined here before, ISO 3166-2 -- as useful 
as it is in other contexts -- is not appropriate for BCP 47 language 
tagging.  Slipping a new entry into the References section will not 
change this.

>> -(xi) On page 79, inside "9.2. Informative References", I would like 
>> to add "Glossary of Terms for the Standardization of Geographical 
>> Names"--United Nations Group of Experts for Geographical 
>> Names--Statistics Division, Department of Economic and Social 
>> Affairs--Manual M85--New York, May 2002.
>
> "Je ne vois pas la nécessité."  --Talleyrand

Since we don't formalize the use of UNGEGN terminology, the only thing 
this reference would accomplish would be to cause IETF Last Call 
reviewers to ask why it was added.

>> 2.2 In fact, I am completely prepared to admit that "political 
>> correctness" has gradually pushed "scientific progress" and ISO 
>> 639/RA-JAC to recognize  "Sign languages", that were not initially 
>> intended to be covered,  as possible entries inside ISO 639-3 and ISO 
>> 639-5 and pseudo-linguistic entities. So we observe in french languge 
>> a shift from "langage des signes", that was historically the only way 
>> to translate "Sign languages" until recently, to "langue des signes" 
>> that became much more politically correct.  But, please, it is not 
>> necessary to rewrite history for this.

I wonder what has caused Gérard to object so strenuously to the encoding 
of sign languages in ISO 639.  Somehow I doubt it is just the origins of 
"langue" and "langage."

--
Doug Ewell  *  Thornton, 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: John Cowan <[email-masked]>
Date: Wed, 8 Oct 2008 00:42:43 -0400

> makes me wish I could write that well.  Clumsily worded addenda follow.

See the .sig.

> and "Bosnian."  I hope my worries are unfounded.

Mmm, you're probably right.

> separated by hyphens" and be done with it.  

There isn't, but it's useful to reassure people that they may use their
RFC 3336- or ISO 8601-compliant routines to read our dates.

> code elements they chose.

Okay with me, then.  Addison?

-- 
John Cowan                                <[email-masked]>
Yakka foob mog.  Grug pubbawup zink wattoom gazork.  Chumble spuzz.
    --Calvin, giving Newton's First Law "in his own words"

Don't be so humble.  You're not that great.             John Cowan
        --Golda Meir                                    [email-masked]
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 7 Oct 2008 22:47:58 -0700

> RFC 3336- or ISO 8601-compliant routines to read our dates.

(editor hat OFF)

I agree. We reference the relevant RFC, which includes the relevant ISO standard bits. That's a good thing.

> Okay with me, then.  Addison?

(editor hat OFF)

I don't agree. We have plenty of text as it is. We don't need to include lots of cruft on behalf of the MA. In practice, we clearly and effectively say that private use is typically a Bad Idea anyway. I especially think it is true of region codes.

Addison