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
(probFrom ltru-bounces at ietf.org Tue Oct 7 10:24:36 2008
Return-Path: <ltru-bounces at ietf.org>
X-Original-To: ltru-archive at megatron.ietf.org
Delivered-To: ietfarch-ltru-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 696D43A68BD;
Tue, 7 Oct 2008 10:24:36 -0700 (PDT)
X-Original-To: ltru at core3.amsl.com
Delivered-To: ltru at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id AA82428C0DE
for <ltru at core3.amsl.com>; Tue, 7 Oct 2008 10:24:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.43
X-Spam-Level:
X-Spam-Status: No, score=-3.43 tagged_above=-999 required=5 tests=[AWL=0.869,
BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id tJt2xrA-zf-6 for <ltru at core3.amsl.com>;
Tue, 7 Oct 2008 10:24:33 -0700 (PDT)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11])
by core3.amsl.com (Postfix) with ESMTP id 247AC3A6873
for <ltru at ietf.org>; Tue, 7 Oct 2008 10:24:33 -0700 (PDT)
Received: from cowan by earth.ccil.org with local (Exim 4.63)
(envelope-from <cowan at ccil.org>)
id 1KnGId-0006Kh-IZ; Tue, 07 Oct 2008 13:24:43 -0400
Date: Tue, 7 Oct 2008 13:24:43 -0400
To: Lang =?iso-8859-1?Q?Gérard?= <gerard.lang at insee.fr>
Message-ID: <20081007172443.GC27156 at mercury.ccil.org>
References: <BLU109-W535C06619B36AB95319120B33C0 at phx.gbl>
<20081003152113.GU31839 at mercury.ccil.org>
<68723E6B2E0EDC4999504D17DDE8F94904AD07DB at S90X2HUB1.ad.insee.intra>
<6.0.0.20.2.20081006185028.06fa4788 at localhost>
<68723E6B2E0EDC4999504D17DDE8F94904AD07DD at S90X2HUB1.ad.insee.intra>
<6.0.0.20.2.20081007092539.096eda28 at localhost>
<68723E6B2E0EDC4999504D17DDE8F94904AD07E4 at S90X2HUB1.ad.insee.intra>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <68723E6B2E0EDC4999504D17DDE8F94904AD07E4 at S90X2HUB1.ad.insee.intra>
User-Agent: Mutt/1.5.13 (2006-08-11)
From: John Cowan <cowan at ccil.org>
Cc: ltru at ietf.org, CE Whitehead <cewcathar at hotmail.com>
Subject: Re: [Ltru] [OT] Re: UNGEGN definitions and UNICODe Glossary of terms
X-BeenThere: ltru at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Language Tag Registry Update working group discussion list
<ltru.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ltru>,
<mailto:ltru-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru at ietf.org>
List-Help: <mailto:ltru-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltru>,
<mailto:ltru-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: ltru-bounces at ietf.org
Errors-To: ltru-bounces at ietf.org
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 cenably 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 lituries) 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 linguisticnguistic 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 bod 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 y]', 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
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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.