(editor hat OFF) You beat me to a response, John, thank you. I agree with your observations. (editor hat ON) I concur with the two minor edits John cited as (vii) and (x) below and will incorporate them into the editor's copy of draft-18. Addison Addison Phillips Globalization Architect -- Lab126 Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On > Behalf Of John Cowan > Sent: Tuesday, October 07, 2008 10:25 AM > To: Lang Gérard > Cc: ltru at ietf.org; CE Whitehead > Subject: Re: [Ltru] [OT] Re: UNGEGN definitions and UNICODe > Glossary of terms > > Summary for Addison: please note points vii, x (first part). > > Lang Gérard scripsit: > > > -(i) On page 10, I do not really understand inside" 2.2.1. > Primary > > Language Subtag" how works the combination of the first and the > third > > paragraph of point 6, that seems to be in contradiction. > > The first paragraph refers to the present, the third to the future. > In English we say "if a ... code is added" rather than "if a > code ... will > be added". > > > The end of the second paragraph of this point 6 is osbcure for me. > What > > is in fact expected ? That no more two alpha-3 code element be > given > > to the same language name inside ISO 639-2, or that when a new > case > > like that occurs no alpha-2 ISO 639-1 code element will be given > to > > this language name ? > > 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. > > > -(ii) On page 13, inside "2.2.4. Region Subtag", I understand > from the > > meaning of the last phrase of point 2. that "UK" that is > effectively > > one of the (today) 10 alpha-2 ISO 3166-1"exceptionally reserved" > code > > element, like "AC", "EU" and "SU", is not to be registered inside > > IANA's Register because GB is already registered. So that "en- > UK" > > is not a possible valid language tag. > > You understand correctly. > > > -(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. > > > -(iv) On page 28, inside "3.1.7 Prefered Value Field", point 1 > that > > writes "ISO 639 language codes that were later withdrawn in favor > of > > othres codes. These values are mostly a historical curiosity. > The > > 'he' / 'iw' pairing above is an example of this" is factually > false > > (even if this has no reaction on IANA's Registry that only > registers > > ISO 639-2T code elements) because ISO 639/RA-JAC decided recently > (on > > 2008-06-28) the deprecation of the ISO 639-2B alpha-3 code > elements > > for the languages "Croatian" and "Serbian", to be replaced by the > > corresponding ISO 639-2T code elements. So this text must be > changed. > > There is no claim that *every* withdrawn ISO 639 code appears in > the > registry, only that some of them do. In particular, the 639-2B > elements > in question never appeared previously in the Registry, and > therefore do > not appear today either. > > > -(v) On page 39, inside "3.4 Stability of IANA Registry Entries", > clause > > F of point 15 (that seems to be in contradiction with the last > phrase > > of clause D of point 4 of 2.2.4., page 14) is absolutely not > useful. It > > is now impossible to add a new entry inside ISO 3166-1 without > giving > > the three corresponding code elements (alpha-2, alpha-3 and > numeric-3) > > to this new entry. In the case, that never occured because "4.1 > List" > > of ISO 3166-1 writes "The list of country names in this part of > ISO > > 3166 ... is based on the list in the "Standard Country or Area > Codes > > for Statisdtical Use" established by the United Nations, that the > > division of statistics of UN would refuse to give a numeric-3 > code > > element concerning a new entry that ISO 3166/MA has decided to > add > > inside ISO 3166-1, ISO 3166/Ma is authorised to choose a numeric- > 3 > > code element inside the specially reserved 901-999 code list. > > This is good news. However, based on unfortunate past experiences, > BCP 47 is written so as to avoid, as much as possible, dependencies > on particular RA or MA policies such as this. > > > -(vi) On page 40, also inside point 15 of 3.4., clause D is > similarly > > of no effect. The case that UN M.49 country or area codes exist > for > > which there is no corresponding ISO 3166-1 code has no existence. > In > > fact, the inverse case exists because old numeric-3 code elements > that > > were given in the past by UN M.49 are still utilised by ISO 3166- > 1 > > even if they are no more effective for UN M.49. This is > specioally > > the case for "158" TAIWAN, but also for "074" BOUVET ISLAND and > "334" > > HEARD ISLAND AND MCDONALD ISLANDS. > > Same comment. > > > -(vii) on page 47, inside "3.6. Possibility of Registration", > that > > gives, in fine, the postal adress concerning ISO 3166/MAS should > be > > lightly modified by replacing the line: "Case postale 56" by the > two > > lines: "1, chemin de la Voie Creuse > > Thank you. > > > -(viii) On page 59, inside "4.1.2. Using Extended Language > Subtag", > > in fine, I completely agree with the first phrase of the last > paragraph > > that writes "Sign languages share a mode of communication rather > than > > a linguistic heritage" and is directly in linewith my previous > messages > > on this point. > > That is to say, they are not descended from another in the way that > French and Spanish are descended from Latin. This is a statement > of > fact, not policy; sign languages have been known to arise > independently > in different parts of the world, though it is true that (e.g.) > American > Sign Language is a descendant of French Sign Language. > > > -(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. > > > -(x) On page 77, inside "9.1. Normative References", dates > concerning > > ISO 639-1 should be precised "July 2002", idem for ISO 639-2 > "October > > 1998, for ISO 639-3 "February 2007" and ISO 646 "December 1991". > > Thank you. > > > ISO 8601 should be added, see (iii). > > See my reply to (iii). > > > 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. > > > -(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 > > > 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. > > [OT] I should characterize this as scientific rather than political > correctness. Speaking of "le langage des signes", which I should > translate as "human gestural communication", covers such things as > nodding or shaking the head to symbolize yes or no, or gestures to > add > emphasis to the spoken voice such as pointed fingers or shaken > fists. > These things are utterly distinct from Deaf sign languages. > > It was in fact a scientific discovery that the communication > systems of > the Deaf were not only an example of "le langage des signes", but > were > also "langues" in their own right, with their own phonologies, > syntaxes, > vocabularies, and semantics. > > As for the derivation of "langue", it is as true in linguistics as > in biology that the historical origin of a feature does not dictate > its current utility: the bones of the mammalian middle ear (malleus, > incus, stapes) were parts of the jaw in the reptilian ancestors, > but > now used to hear rather than to chew; and although _chef_ in French > derives from Latin _caput_ 'head [of the body]', it would be > entirely > incorrect to use _chef_ instead of _tête_ (from Latin _testa_ 'pot') > to mean 'head' today. Such changes are always going on, and if > "langue" > now covers languages that do not require a tongue to speak, it is > neither > surprising nor inaccurate. > > -- > John Cowan cowan at ccil.org http://ccil.org/~cowan > Half the lies they tell about me are true. > --Tallulah Bankhead, American actress > _______________________________________________ > Ltru mailing list > Ltru at ietf.org > https://www.ietf.org/mailman/listinfo/ltru _______________________________________________ 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.