Subject: Re: [Ltru] Ltru Digest, Vol 48, Issue 24

From: Lang Gérard <[email-masked]>
Date: Wed, 11 Feb 2009 12:22:29 +0100

Dear All,

Concerning the last proposition regarding "E" and Channel Islands, some more informations.

1-History: inside the first edition of ISO 3166 (1974), that only had the alpha-2 and the alpha-3 codes, the entry GB (United Kingdom of Great Britain and Northern Ireland) was commented by a remark "Includes Orkney, Shetland and Channel Islands and Isle of Man".
Inside the second edition of ISO 3166 (1981), that integrated as a third ISO 3166 country code the numeric-3 code M49 from the United Nations Statistics Division (UNSD), all entries of the M49 code became entries of ISO 3166, with the only exception (asked by GB) of both Channel Islands and Isle of Man, so that the remark concerning GB remained unchanged [By the way, and on the other hand, this integration comprised obtaining from UNSD numeric-3 code elements for all entries of the first edition of ISO 3166, like Bouvet Island (BV, BVT, 074) or Heard and McDonald Islands (HM, HMD, 334), that became new entries inside M49 ;but some of these new entries were almost immediatly (1982) suppressed from M49 !].
 Another interesting fact is that a paper version  (01/06/1992) prepared by UNSD of the "Standard country or area code for statistical use" (this is the initial official name of M49) included a line "833  Isle of Man  IM   IMY"  containing alpha-2 and alpha-3 ISO 3166 code elements that did not exist at this date (and were published by UNSD until 2000 at least), the alpha-2 being the correct would-be one, but not the alpha-3 !!
The remark concerning GB remained the same in the third edition (1988), but was precised in the fourth edition (1993) as follows:
"Includes Orkney Islands and Shetland Islands; the code elements are also applicable to the Channel Islands, and the Isle of Man which are direct dependancies of the British Crown", so as to allow GB to explain the fact that Channel Islands and Isle of Man are no really covered by the name "United Kingdom of Great Britain and Northern Ireland"
Inside the fitfh edition (1997) of ISO 3166 (first edition of ISO 3166-1), the remark concerning GB was simplified as follows: "Includes the Channel Islands, the Isle of Man".
On 29-03-2004, ISO 3166-1 Newsletter V-11 decided to create inside ISO 3166-1 the three new entries GUERNSEY (GG, GGY, 831), ISLE of MAN (IM, IMN, 833) and JERSEY (JE, JEY, 832) and suppressed any remark concerning GB. At the same time UNSD, that had created the numeric-3 code elements 831 and 832 at ISO 3166/MA request, added Guernsey and Jersey as two new entries inside M49 (but did not suppress the entry Channel Islands, as should, or could, have been the case). The sixth edition of ISO 3166 (second edition of ISO 3166-1), published on 15-11-2006, integrated the Newsletter V-11.
On 09-09-2008, ISO 3166-1 Newsletter VI-3 added a remark concerning GG as follows "The Bailiwick of Guersey also includes the islands of Alderney, Breqhou, Burhou, Herm, Jethou, Lihou, Little Sark and Sark".

2-Coherence: if it is correct that Channel Islands is today the only entry of M49 that is not an entry of ISO 3166-1, it must also be remarked that some entries of ISO 3166-1, like BV or HM, are no more today's entries for M49.
Moreover, M49 added to the section concerning "countries and territories" another section concerning macroregions and giving, on one side a list of geographical macro-regions (continents, subcontinents and continental regions, that is considered inside RFC 4646 (and also indirectly inside ISO 3166-1 because, as application of the clauses 8.1.2 and 8.1.3 concerning user-assigned use of reserved code elements for aggregations of countries, ISO 3166/MA recommands alignment for such use with a notified assignation) and, on another side a list of economic grouping of countries (like developped, developping, least developped, landlocked, ..) that is not used by ISO 3166 or RFC 4646. .

3-Terminology: In the common terminology of ISO 3166 and ISO 639, a code is a table making a link between on one side a list of entries (Country names, Language names) and a corresponding list of code elements, built by use of a coding scheme defined by a syntactic format (like alpha-2, alpha-3 or numeric-3) and maybe other rules (like a visual association between the alphabetic code elements and the corresponding entry names). So that "830" is a "code element" and should not be considered as a "code".

4-Anyway, in my opinion, this text "E" could very well be suppressed. 

Bien cordialement.
Gérard LANG

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 10 février 2009 22:36
À : [email-masked]
Objet : Ltru Digest, Vol 48, Issue 24

Send Ltru mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/ltru
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Ltru digest..."

Today's Topics:

   1. Issue #1: change ref from 2434 to 5226 (Randy Presuhn)
   2. Re: draft-21 mod: move RFC 4645 reference to informative
      (John Cowan)
   3. Issue #2:  move 2860 ref to informative (Randy Presuhn)
   4. Issue #3: move RFC 4645 reference to informative (Randy Presuhn)
   5. Issue #5: change "apply" (Randy Presuhn)
   6. Issue #6: change "the ones" (Randy Presuhn)

----------------------------------------------------------------------

Message: 1
Date: Tue, 10 Feb 2009 13:32:25 -0800
From: "Randy Presuhn" <[email-masked]>
Subject: [Ltru] Issue #1: change ref from 2434 to 5226
To: "LTRU Working Group" <[email-masked]>
Message-ID: <008e01c98bc7$1148b460$6801a8c0@oemcomputer>
Content-Type: text/plain;	charset="iso-8859-1"

Hi -

This was assigned issue #1.

Randy

----- Original Message ----- 
> From: "Phillips, Addison" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Sunday, February 08, 2009 9:20 AM
> Subject: [Ltru] draft-21 mod: change ref from 2434 to 5226
>
> [this is the first email reporting changes between the current 
> official draft, which is draft-20, and the editor copy, which is
draft-21]
>
> Issue: update reference from RFC 2434 to RFC 5226
>
> Resolution: completed in draft-21; 2434 was obsolete by 5226
>
> Addison Phillips
> Globalization Architect -- Lab126
>
> Internationalization is not a feature.
> It is an architecture.
>
>
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru

------------------------------

Message: 2
Date: Tue, 10 Feb 2009 16:32:44 -0500
From: John Cowan <[email-masked]>
Subject: Re: [Ltru] draft-21 mod: move RFC 4645 reference to
	informative
To: Randy Presuhn <[email-masked]>
Cc: LTRU Working Group <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Randy Presuhn scripsit:

> > For historical reasons, the UN numeric code 830 (Channel Islands), 
> > which was not registered at the time this document was adopted and 
> > had, at that time, no corresponding ISO 3166-1 code, MAY be entered 
> > into the IANA registry via the process described in Section 3.5, provided no ISO 3166-1 code with that exact meaning has been previously registered.
> ...
> 
> As co-chair...
> This seems to be our best "minimum change" proposal for this paragraph 
> so far.  Are there any objections to adopting Addison's proposed text?

I'd strike "for historical reasons", which seems unnecessary to me.

-- 
What is the sound of Perl?  Is it not the       John Cowan
sound of a [Ww]all that people have stopped     [email-masked]
banging their head against?  --Larry            http://www.ccil.org/~cowan

------------------------------

Message: 3
Date: Tue, 10 Feb 2009 13:33:05 -0800
From: "Randy Presuhn" <[email-masked]>
Subject: [Ltru] Issue #2:  move 2860 ref to informative
To: "LTRU Working Group" <[email-masked]>
Message-ID: <009301c98bc7$29371bc0$6801a8c0@oemcomputer>
Content-Type: text/plain;	charset="iso-8859-1"

Hi -

This was assigned issue #2.

----- Original Message ----- 
> From: "Phillips, Addison" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Sunday, February 08, 2009 9:21 AM
> Subject: [Ltru] draft-21 mod: move 2860 ref to informative
>
> Issue: move the reference to RFC 2860 "Memorandum of Understanding 
> Concerning the Technical Work of the Internet Assigned Numbers 
> Authority" from normative to informative
> 
> Resolution: completed in draft-21 by request of one of the co-chairs.
> 
> Addison Phillips
> Globalization Architect -- Lab126
> 
> Internationalization is not a feature.
> It is an architecture.
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru

------------------------------

Message: 4
Date: Tue, 10 Feb 2009 13:33:52 -0800
From: "Randy Presuhn" <[email-masked]>
Subject: [Ltru] Issue #3: move RFC 4645 reference to informative
To: "LTRU Working Group" <[email-masked]>
Message-ID: <009801c98bc7$45888f20$6801a8c0@oemcomputer>
Content-Type: text/plain;	charset="iso-8859-1"

Hi -

this was assigned issue #3.

Randy

> From: "Phillips, Addison" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Sunday, February 08, 2009 9:23 AM
> Subject: [Ltru] draft-21 mod: move RFC 4645 reference to informative
>
> Issue: move RFC 4645 reference to informative
>
> Resolution: moved to the informative section from the normative 
> section. The "normative" material in 4645 in question isn't up to
the standard of having a normative reference.
>
> Addison Phillips
> Globalization Architect -- Lab126
>
> Internationalization is not a feature.
> It is an architecture.
>
>
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru

------------------------------

Message: 5
Date: Tue, 10 Feb 2009 13:34:49 -0800
From: "Randy Presuhn" <[email-masked]>
Subject: [Ltru] Issue #5: change "apply"
To: <[email-masked]>
Message-ID: <009d01c98bc7$679d88e0$6801a8c0@oemcomputer>
Content-Type: text/plain;	charset="utf-8"

Hi -

This was assigned issue #5.

Randy

> From: "Phillips, Addison" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Sunday, February 08, 2009 9:29 AM
> Subject: change "apply"
>
> Issue:
>
> >
> > ...
> > >  ?? Also, CHANGE: "apply" to "adhere to" or simply "follow"  (I
> > like "adhere to" better;
> > > "apply" might be a word you use with applications and rules but I
> > do not use it with anything but formatting,
> > > "formatting is applied . . ."
> >
>
> Randy commented:
>
> > Disagree.  I see no need for this change.
>
> Resolution: no change. The editors don't see a reason to modify this.
>
> Addison Phillips
> Globalization Architect -- Lab126
>
> Internationalization is not a feature.
> It is an architecture.
>
>
> >
> > ...
> > >  ? Also, CHANGE:  "the ones" to "those" (I think the the text is
> > more cohesive with 'those'
> > > because it refers back to 'the rules'--this is an idea that
> > Halliday has about cohesion too) }
> >
> > Disagree.  I see no need for this change.
> >
> > > "Standards, protocols, and applications that reference this
> > document
> > >   normatively but adhere to rules different than those given in
> > this section . . . "
> >
> > This proposed usage of "than" is simply wrong, and I cannot support 
> > it.
> >
> > ...
> > > ! 4.1 par 6 item 1 second bullet
> > >
> > > {ORIGINAL TEXT }
> > > " Note that some subtag sequences might not represent the
> > >           language a casual user might expect, especially if when
> > >           relying on the subtag's description in the registry. "
> > >
> > > {! CORRECTION:  delete either "if" or "when" as "if when" seems a
> > bit redundant, right? }
> >
> > Yup.  However, the entire phrase "especially...registry" is not 
> > helpful to the sense of the paragraph in question.  Consequently, I 
> > think that if a change is to be made, it would be better to delete 
> > everything from the comma to the word "registry".
> >
> > ...
> > > ! 4.3 Par 1 Bullet 1 last sentence
> > >
> > > {ORIGINAL TEXT}
> > >    "o  A language priority list [RFC4647] describing a user's
> > language
> > >        preferences.  This is a (possibly weighted) list of
> > potentially-
> > >       unrelated varieties, expressing a preference, rather than
> > as a
> > >       declaration about actual content."
> > ...
> > > "This is a (possibly weighted) list of potentially unrelated
> > varieties,
> > >  expressing a preference, rather than a declaration of actual
> > content."
> >
> > Yup.  However, this sentence is entirely redundant, so if there is 
> > going to be a change, I'd rather just delete it.
> >
> > > ! 5.1, par 4, sentence 2
> > >
> > > { ORIGINAL TEXT }
> > >
> > > " Inserted records can be placed anywhere in the appropriate
> > section; there is
> > >   no guarantee of the order of the records beyond grouping them
> > together by 'Type'."
> > ...
> > > "Inserted records can be placed anywhere in the appropriate
> > section; there
> > > is no guarantee of their order beyond their being grouped
> > together by 'Type'."
> >
> > Ok.  This "can" probably should be a MAY, but it's not a big deal 
> > and it's not worth changing.
> >
> > ...
> > > ! 4.4.2 Par 1, last sentence
> > >
> > > { ORIGINAL TEXT }
> > >
> > > "  Such truncation MUST NOT
> > >    permit a subtag to be chopped off in the middle or the
> > formation of
> > >    invalid tags (for example, one ending with the "-"
> > character)."
> > ...
> > > "Such truncation MUST NOT permit the formation of invalid tags-- 
> > > either by chopping a subtag off in the middle, or by leaving a
> > singleton without any subtag."
> >
> > Disagree.  The original text is gramamtically and technically 
> > correct.
> > The proposed text changes the meaning in a subtly  incompatible way.
> > Consider the case where chopping a subtag in the middle does *not* 
> > result in an invalid tag, but instead produces a tag containing a 
> > subtag not present in the original.
> >
> > ....
> > > ? 3.5  "Registration Procedure for Subtags" Par 4, 2nd sentence
> > >
> > > { ORIGINAL TEXT }
> > >
> > > " Note that each response is not limited in
> > >    size so that the request can adequately describe the
> > registration."
> > >
> > > {COMMENTS: the word "response" is not clear here, and this
> > sentence
> > > is awkward and unclear as a whole.
> >
> > I think the sentence is abundantly clear in context, and see no need 
> > for change.
> > ...
> >
> > > ? 3.7 par 4 & 5
> > ...
> > > {COMMENT:  the two maintaining authorities, IANA, and the
> > individual
> > > authority, might be confused by readers here??
> > ...
> >
> > Given the topic of the section, I find it difficult to imagine such 
> > confusion taking place.
> >
> > > "Failure on the part of the maintaining authority to maintain
> > this record  . . . "
> >
> > It's difficult to keep a straight face when reading the proposed 
> > replacement.
> >
> > ...
> > > ? 4.1 Par 5
> > >
> > > { ORIGINAL TEXT }
> > >
> > > " A subtag SHOULD only be used when it adds useful distinguishing
> > >    information to the tag.  Extraneous subtags interfere with the
> > >    meaning, understanding, and processing of language tags.  In
> > >    particular, users and implementations SHOULD follow the
> > 'Prefix' and
> > >    'Suppress-Script' fields in the registry (defined in Section
> > 3.1):
> > >    these fields provide guidance on when specific additional
> > subtags
> > >    SHOULD be used or avoided in a language tag."
> > >
> > > {COMMENT/CORRECTION for Sentence 1:
> > >  the way it's written, someone might interpret it as meaning that
> > all subtags,
> > >  including a primary language subtag, are optional, but a primary
> > language
> > > subtag is really a good idea, a real SHOULD}
> > >
> > > INSERT AT BEGINNING--replace sentence 1 with 2 sentences
> > >
> > > "All language tags--except those that are exclusively private
> > use--
> > > SHOULD include one (primary) language subtag.  Any additional 
> > > subtag SHOULD only be included when it adds useful distinguishing 
> > > information to the tag. "
> >
> > Strongly disagree.  This changes the sense of the text.
> > [As co-chair: it took extensive discussion to reach agreement on 
> > this text, and I'm extremely relectuant to even consider changes to 
> > it unless something is demonstrably broken.]
> >
> > > ?? {A SECOND COMMENT/CORRECTION for Sentence 3:  word choice; 
> > > change "follow" to "consult"  I would never say "follow"
> > > for either unless I said "follow the guidelines . . ."; "consult"
> > > is the best word with "users" probably; not sure at all about 
> > > implementations but I would not say "follow"}
> >
> > Disagree.  While I appreciate the preference for "consult", it does 
> > not mean the same thing as "follow".
> >
> > ...
> > > ? 4.1 par 6 item 2 example second bullet last sentence
> > >
> > > { ORIGINAL TEXT }
> > >
> > > "(The tag "uz-Zxxx"
> > >        could also be used where content is not written, as the
> > subtag
> > >         'Zxxx' represents the "Code for unwritten documents".)"
> > >
> > > { COMMENT/CORRECTION I do not see what clarity or information the 
> > > word 'code' adds to this sentence so I CORRECTED it }
> >
> > I believe it's a quote from the subtag's registry enty.
> >
> > > "The tag "uz-Zxxx"
> > >         could also be used where content is not written as the
> > script subtag 'Zxxx' is used to indicate unwritten documents"
> >
> > I think this would be a step backwards, since it de-emphasizes the 
> > generative nature of subtags.
> >
> > ...
> > > ? 4.1.1 par 5, last sentence
> > >
> > > ORIGINAL TEXT }
> > >
> > > "For example, Romanian ('ro') and
> > >    Moldavian ('mo') do not share a macrolanguage, but are far
> > more
> > >    closely related to each other than Cantonese ('yue') and Wu
> > ('wuu') ,
> > >   which do share a macrolanguage."
> > > {! COMMENT:  the [ro] [mo] example is a bit of a problem as one
> > of the
> > > subtags has now been deprecated; [ca] and [oc], 'Catalan' and 
> > > 'Occitan'/'Provencal,' would be better examples; alternately you 
> > > might choose [gsw] 'Alsatian' or 'Schwyzerd?tsch'
> > >  and [swg] 'Swabian'--but I know less about Alsatian; There may be 
> > > other possibilities; on a quick perusal of RFC 4645  I did not 
> > > find khmer, for example, though I discovered there are
> > some
> > >  maybe mutually intelligible varieties any & know little about
> > Asian
> > > languages anyway}
> >
> > Strongly disagree.  The example serves its purpose as it is, and 
> > none of the cases cited is as dramatic and clear-cut as that of 
> > Romanian and Moldavian.  (Which explains nicely
> > *why* the subtag met the fate that it did.)
> >
> > [As co-chair: there already seems to be a rough consensus to not 
> > change this section.]
> >
> > > 4.2 par 5
> > >  { ORIGINAL TEXT }
> > > "   This relationship is not guaranteed in all cases:
> > specifically,
> > >    languages that begin with the same sequence of subtags are NOT
> > >    guaranteed to be mutually intelligible, although they might be.
> > For
> > >    example, the tag "az" shares a prefix with both "az-Latn"
> > >    (Azerbaijani written using the Latin script) and "az-Cyrl"
> > >    (Azerbaijani written using the Cyrillic script).  A person
> > fluent in
> > >    one script might not be able to read the other, even though
> > the
> > >    linguistic content (e.g., what would be heard if both texts
> > were read
> > >    aloud) might be identical.  Content tagged as "az" most
> > probably is
> > >    written in just one script and thus might not be intelligible
> > to a
> > >    reader familiar with the other script."
> > > {COMMENT/CORRECTION  I found the language, 'this relationship is 
> > > not guaranteed,' kind of vague. Also I did not like the phrase,
> > 'written
> > > in just one script'--an example specifying one of the two scripts
> > might help
> > > make this sentence clearer to someone skimming this.  I tried to
> > rewrite
> > > this paragraph:  I simplified the first sentence and used more
> > specific
> > > language (the word 'always' here, does refer the reader back to
> > what's
> > > been said in the paragraph above about the general relationship
> > between
> > > language tags sharing a prefix--one that we now see does not
> > always
> > > guarantee mutual intelligibility); I also rewrote slightly the
> > second sentence,
> > > and inserted "however" (to tie back to the previous statement) 
> > > "only" into the fourth sentence.}
> > >
> > > ?? "Tags that share the same prefix are not always mutually
> > intelligible.
> > >  For example, the prefix 'az' is shared by both  "az-Latn"
> > (Azerbaijani
> > > written using the Latin script) and "az-Cyrl" (Azerbaijani
> > written using
> > > the Cyrillic script). A person fluent in one script might not be
> > able to
> > > read the other, even though the
> > > linguistic content (e.g., what would be heard if both texts were
> > read
> > > aloud) might be identical. However, content tagged as "az" most 
> > > probably is written in just one of these scripts and thus might
> > not
> > > be intelligible to a reader familiar with only the other script."
> >
> > Disagree.  The change to the first sentence makes it sound like 
> > mutual intelligibility is normally presumed when there is a shared 
> > prefix, and that cases like this are rare exceptions.  The existing 
> > text is clearer and more to the point.
> >
> > > ? 4.5 par 2  item 4 & par 4 "Example . . . "
> > ...
> > > { COMMENT/CORRECTION: the first example actually goes with item
> > > 5 & the second with item 4 so it's confusing; I prefer to have
> > the examples
> > > with the items they illustrate; thus I'd move the second of the
> > examples
> > > so that it followed item 4-- }
> >
> > I'm neutral on this proposal.  I see the benefits to interspersing 
> > the examples with the list of rules, but I also see advantages to 
> > the current organization with the examples following the rules.
> > I'm not persuaded at all that this is a change that in any way
> > *needs* to be made.
> >
> > ...
> > > ?? 3.5 par 21
> > ...
> > > {! COMMENT/CLARIFICATION ?  Please explain "SHALL NOT" versus
> > "MUST NOT"--
> >
> > This is spelled out in RFC 2119.
> >
> > Randy
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ltru
>

------------------------------

Message: 6
Date: Tue, 10 Feb 2009 13:35:46 -0800
From: "Randy Presuhn" <[email-masked]>
Subject: [Ltru] Issue #6: change "the ones"
To: <[email-masked]>
Message-ID: <00a201c98bc7$89663760$6801a8c0@oemcomputer>
Content-Type: text/plain;	charset="utf-8"

Hi -

This was assigned issue #6.

Randy

> From: "Phillips, Addison" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Sunday, February 08, 2009 9:30 AM
> Subject: change "the ones?"
>
> Issue:
> 
> > ...
> > >  ? Also, CHANGE:  "the ones" to "those" (I think the the text is
> > more cohesive with 'those'
> > > because it refers back to 'the rules'--this is an idea that
> > Halliday has about cohesion too) }
> > 
> > Disagree.  I see no need for this change.
> > 
> 
> Resolution: no change. Purely editorial request.
> 

------------------------------

_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

End of Ltru Digest, Vol 48, Issue 24
************************************