Subject: [Ltru] Re: The "QU" territory/region code

From: "Doug Ewell" <[email-masked]>
Date: Tue, 13 Nov 2007 07:20:37 -0800

Martin Duerst <duerst at it dot aoyama dot ac dot jp> wrote:

> What I'm a bit worried about, and would like to see some confirmation, 
> is the following scenario. Assume for one reason or another, some EU 
> variant of a language develops, is defined, or what not.

Back to this in a moment.

> Obviously at least to me, the region subtag 'EU' would be most suited 
> in this case. Is it possible that the ietf-languages list just adds 
> this subtag to the registry, or would we have to convene a WG and 
> write another version of what's currently RFC 4646? If the later is 
> the case, my preference would be to carefully tweak our texts so that 
> we can avoid rechartering just for the potential scenario described 
> above.

Both RFC 4646 and draft-4646bis is that they refer to code elements 
"assigned" in ISO 3166-1.  RFC 4645 uses the terms "valid" and 
"assigned" in populating the initial LSR.  Exceptionally reserved code 
elements are not "assigned" according to the ISO 3166/MA definition, and 
thus they don't qualify to have region subtags derived from them 
according to our definition.  We would need to change the requirements 
in 4646bis, and possibly in 4645bis, or else recharter the group to do 
this in the future.

As Addison said, if we really need a region subtag EU, someone needs to 
petition ISO 3166/MA to assign the code element.

This discussion, however, continues to presume a (potential) need for a 
region subtag to describe language usage in exactly these countries (as 
of 2007-11-03):

AT, BE, BG, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HU, IE, IT, LT, LU, 
LV, MT, NL, PL, PT, RO, SE, SI, SK

and all of their dependencies, but NOT neighboring countries such as 
Iceland, Norway, Switzerland, or the Baltics.  And the list of EU 
countries changes with some regularity -- there are currently three 
"official candidate states" and four "potential candidates" -- making 
code instability not merely a possibility, as it is with all country 
coding systems, but a certainty.

This is not at all (IMHO) like the recent addition of BL and MF to 3166 
and the LSR, two countries (if that they are) which don't appear to 
exhibit distinct language usage.  In that case, we are mirroring the 
decisions made by ISO 3166/MA, as we claim to do, without consideration 
of the linguistic angle.  In the case of EU, we are actively seeking an 
exception to our rules, which implies we must have a pretty good reason 
to do so.

Thanks to numeric region codes based on UN M.49, we now have lots of way 
to indicate pan-European usage: 039, 150, 151, 154, 155.  This has 
nothing to do with serving the language-tagging needs of Europe.

Bureaucratic jargon is NOT a regional variation; as Frank said, a 
variant would be better suited to this.  Even Michael Everson's famous 
crusade against use of "euro" as a plural was NOT an instance of "EU 
usage," but rather a misinterpretation of an EU directive by local Irish 
officials and journalists.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
NEW E-MAIL -->  dewell at roadrunner dot com
NEW URL -->  http://home.roadrunner.com/~dewell
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ 

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

---

From: Addison Phillips <[email-masked]>
Date: Tue, 13 Nov 2007 09:59:36 -0800

What follows is a bit of a rant, albeit with a textual propose for our 
draft (remember our draft?). Pardon my dust. :-)

Okay, here's my concern: there was, at one time, a very long and 
not-very-friendly thread on ietf-languages in which folks mostly from 
the software industry attempted (and failed) to register "es-americas" 
to identify some kind of Latin American or mid-Atlantic Spanish. The 
argument against this (basically) was that there was no such "real" 
language, as in "a language recognized by linguistic scholars". There 
were, however, some who thought they had a quite real need to identify 
an artificially created linguistic variant.

In RFC 4646 we explicitly acknowledged the potential for use of the UN 
M.49 code "419" for this purpose.

I agree with Doug that one of the UN M.49 codes could be used to 
identify an artificial linguistic variant for the EU. However, I would 
be unsurprised if, for example, the EC were to adopt specially 
controlled language variations for translating EU "stuff" without having 
to choose particular local variants (or translate into all of them). 
Thus I can imagine an "fr-EU" or "de-EU" which is both "not a real 
language" and also not "fr-FR" or "de-DE". This could also be addressed 
as "fr-x-euro" or "de-eunion" or some-such.

What bothers me is the sense that "we" (there is no "we") know better 
than the users making the request about their application's needs. I 
tend to be a little more promiscuous about supporting variants as a 
result. There are cases where the thing being requested isn't well 
thought out. But I am not altogether happy with the notion that there is 
only one way to use language tags or that "there is no such language as 
X hence no use for this subtag in language tags". We don't actually know 
that.

So: I think it would be just grand if 'EU' were actually assigned by ISO 
3166 and not just reserved. Further, I would support our acknowledging 
the "exceptional reservation" as "an assignment" in 4646bis. To that 
end, I'd propose changing Section 2.2.4, item 2 in the list to read:

--
All two-character subtags following the primary subtag, with one 
exception, were defined in the IANA registry according to the 
assignments found in [ISO3166‑1] (International Organization for 
Standardization, “ISO 3166-1:1997. Codes for the representation of names 
of countries and their subdivisions -- Part 1: Country codes,” 1997.) 
("Codes for the representation of names of countries and their 
subdivisions -- Part 1: Country codes") using the list of alpha-2 
country codes, or using assignments subsequently made by the ISO 3166 
maintenance agency or governing standardization bodies. The one 
exception is the code 'EU' (European Union), which is "exceptionally 
reserved" for that purpose (but not "assigned") by ISO 3166. This code 
is assigned in the registry and is subject to the same constraints that 
appear elsewhere in this document as if it were actually assigned by ISO 
3166.
--

Regards,

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 13 Nov 2007 18:07:10 -0800

+1

I firmly agree. BCP 47 is not only the source of language tags; it is
*the *reference
for stabilized, maintainable codes for languages, scripts, and regions.
Someone citing "regions as defined by BCP 47", even when not used in
language codes, has a stable, well-defined, maintainable code that also
encompasses UN M.49 regions. And this is a good thing, since it promotes the
use *and interworkability *with BCP 47, and software internationalization
overall.

By excluding edge cases like EU, we just make it harder for people to use
BCP 47 as is, and force the proliferation of private use codes (or worse
yet, non-BCP47 codes).

By being pragmatic, and handling just a few key cases that are important for
implementations, we make it far easier for people to adopt and use BCP 47.
Adding "EU" to 4646bis would be one of those key cases. It doesn't hurt to
have EU as a code in BCP 47, no more than it hurts to have BV as a code. And
the EU is a darn'd sight more important than a slew of the region codes we
already have -- whether in language codes or in interworking with them!

I agree with Addison's proposed text.

Mark

On Nov 13, 2007 9:59 AM, Addison Phillips <[email-masked]> wrote:

> Standardization, "ISO 3166-1:1997. Codes for the representation of names
> of countries and their subdivisions -- Part 1: Country codes," 1997.)

-- 
Mark

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 14 Nov 2007 10:11:28 +0100

Doug Ewell wrote:

> NOT neighboring countries such as Iceland, Norway, Switzerland,
> or the Baltics.

s/or the Baltics/Andorra, Foroyar, Holy See, Liechtenstein, Monaco, or San Marino/.

> And the list of EU countries changes with some regularity

Yep, the EU might soon get Kosovo, Kroatia, and Montenegro as new members.
Of course the LSTR will get a code for Kosovo first... ;-)

 Frank

---

From: "Debbie Garside" <[email-masked]>
Date: Wed, 14 Nov 2007 10:50:37 -0000

Hi Addison

I am attending the next meeting of the ISO 3166-1 MA on the 31st of January 
2008 on behalf of the BSI.   If it would help to have this code allocated 
within ISO 3166-1 I would be happy to put forward a proposal to the other MA 
members.  When writing any proposal please be mindful of the criteria for 
inclusion within ISO 3166-1.  If you can make the proposal fit the inclusion 
criteria I will present and support it.

Best regards

Debbie Garside

> -----Original Message-----
> From: Addison Phillips [mailto:[email-masked]]
> Sent: 13 November 2007 18:00
> To: Doug Ewell
> Cc: LTRU Working Group
> Subject: Re: [Ltru] Re: The "QU" territory/region code
>
> What follows is a bit of a rant, albeit with a textual
> propose for our draft (remember our draft?). Pardon my dust. :-)
>
> Okay, here's my concern: there was, at one time, a very long
> and not-very-friendly thread on ietf-languages in which folks
> mostly from the software industry attempted (and failed) to
> register "es-americas"
> to identify some kind of Latin American or mid-Atlantic
> Spanish. The argument against this (basically) was that there
> was no such "real"
> language, as in "a language recognized by linguistic
> scholars". There were, however, some who thought they had a
> quite real need to identify an artificially created
> linguistic variant.
>
> I agree with Doug that one of the UN M.49 codes could be used
> to identify an artificial linguistic variant for the EU.
> However, I would be unsurprised if, for example, the EC were
> to adopt specially controlled language variations for
> translating EU "stuff" without having to choose particular
> local variants (or translate into all of them).
> Thus I can imagine an "fr-EU" or "de-EU" which is both "not a
> real language" and also not "fr-FR" or "de-DE". This could
> also be addressed as "fr-x-euro" or "de-eunion" or some-such.
>
> What bothers me is the sense that "we" (there is no "we")
> know better than the users making the request about their
> application's needs. I tend to be a little more promiscuous
> about supporting variants as a result. There are cases where
> the thing being requested isn't well thought out. But I am
> not altogether happy with the notion that there is only one
> way to use language tags or that "there is no such language
> as X hence no use for this subtag in language tags". We don't
> actually know that.
>
> 3166 and not just reserved. Further, I would support our
> acknowledging the "exceptional reservation" as "an
> assignment" in 4646bis. To that end, I'd propose changing
> Section 2.2.4, item 2 in the list to read:
>
> --
> assignments found in [ISO3166-1] (International Organization for

---

From: Martin Duerst <[email-masked]>
Date: Wed, 14 Nov 2007 19:54:05 +0900

At 02:59 07/11/14, Addison Phillips wrote:

>So: I think it would be just grand if 'EU' were actually assigned by ISO 3166 and not just reserved. Further, I would support our acknowledging the "exceptional reservation" as "an assignment" in 4646bis.

What other codes except for "EU" are there? I'm fine to restrict this to "EU"
only, but I just want to cross-check.

>To that end, I'd propose changing Section 2.2.4, item 2 in the list to read:
>
>--
>All two-character subtags following the primary subtag, with one exception, were defined in the IANA registry according to the assignments found in [ISO3166$Bc`A(B] (International Organization for Standardization, $Bc`W*(BSO 3166-1:1997. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes,$Bc`Y(B1997.) ("Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes") using the list of alpha-2 country codes, or using assignments subsequently made by the ISO 3166 maintenance agency or governing standardization bodies. The one exception is the code 'EU' (European Union), which is "exceptionally reserved" for that purpose (but not "assigned") by ISO 3166. This code is assigned in the registry and is subject to the same constraints that appear elsewhere in this document as if it were actually assigned by ISO 3166.
>--

As a technical contributor, I agree with this text addition for the reasons given
by Addison. However, the text has to be fixed to be in pure US-ASCII.

Regards,    Martin.s

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 14 Nov 2007 12:12:56 +0100

> only, but I just want to cross-check.

Tons of bogus codes, compare

http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/iso_3166-1_decoding_table.html?printable=true#AA

EU is in the yellow set (exceptionally reserved), like AC, CP, DG,
EA, FX,  IC, TA, and UK.  Opening this can of worms is suicidal.

 Frank

---

From: John Cowan <[email-masked]>
Date: Wed, 14 Nov 2007 08:40:01 -0500

> criteria I will present and support it.

I think it's impossible for the MA to call the European Union a nation,
particularly since their assigned codes are slaved to M.49, which
has no code for it.

-- 
What has four pairs of pants, lives             John Cowan
in Philadelphia, and it never rains             http://www.ccil.org/~cowan
but it pours?                                   [email-masked]
        --Rufus T. Firefly

---

From: John Cowan <[email-masked]>
Date: Wed, 14 Nov 2007 08:59:26 -0500

Frank Ellermann scripsit:

> EA, FX,  IC, TA, and UK.  

That is to say, Ascension Island, Clipperton Island, Diego Garcia, Ceuta
and Melilla, France without the overseas territories, the Canary Islands,
Tristan da Cunha, and the U.K.  Of these, only the last code is really
bogus, poison, or wormy.  I think we could easily live with the others:
indeed, en-TA is a recognized variety of English.

So I'd be happy to see the exceptionally reserved codes available
with the exception of UK.

-- 
The Unicode Standard does not encode            John Cowan
idiosyncratic, personal, novel, or private      http://www.ccil.org/~cowan
use characters, nor does it encode logos
or graphics.                                    [email-masked]

---

From: John Cowan <[email-masked]>
Date: Wed, 14 Nov 2007 09:06:25 -0500

Addison Phillips scripsit:

> 3166 and not just reserved. 

As I said, I don't think that's practical.

> I'd propose changing Section 2.2.4, item 2 in the list to read:

Here's my proposed version:

All two-character subtags following the primary subtag were defined in
the IANA registry according to the assignments found in [ISO3166‑1]
(International Organization for Standardization, “ISO 3166-1:1997. Codes
for the representation of names of countries and their subdivisions --
Part 1: Country codes,” 1997.)  ("Codes for the representation of names
of countries and their subdivisions -- Part 1: Country codes") using the
list of alpha-2 country codes, or using assignments subsequently made by
the ISO 3166 maintenance agency or governing standardization bodies. In
addition, the codes that are "exceptionally reserved" (as opposed to
"assigned") in ISO 3166-1 were also defined in the registry, with the
exception of 'UK', which is an exact synonym for the assigned code
'GB'.  It would only be confusing to allow 'UK', so it is excluded.

Yeah, it's cherry-picking, but this particular cherry has a worm in it.

-- 
John Cowan  http://ccil.org/~cowan  [email-masked]
All "isms" should be "wasms".   --Abbie

---

From: Misha Wolf <[email-masked]>
Date: Wed, 14 Nov 2007 14:23:03 +0000

I would make the statement about excluding 'UK' stronger.  I can't 
propose specific words, but the inclusion of 'UK' would break 
matching, so qualifies for stronger language than just "confusing".

Misha

-----Original Message-----
From: John Cowan [mailto:[email-masked]] 
Sent: 14 November 2007 14:06
To: Addison Phillips
Cc: Doug Ewell; LTRU Working Group
Subject: Re: [Ltru] Re: The "QU" territory/region code

This email was sent to you by Reuters, the global news and information company. 
To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, 
except where the sender specifically states them to be the views of Reuters Limited.

Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company.
Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom
Registered No: 3296375
Registered in England and Wales
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Addison Phillips <[email-masked]>
Date: Wed, 14 Nov 2007 07:38:20 -0800

I agree with John's proposed wording.

I agree with Misha's note too. We could just omit John's last sentence 
(the explanation is sufficiently grave on its own).

I kind of like the fact that we point out somewhere that 'UK' is not the 
right code to use for the UK in a language tag.

Addison

Misha Wolf wrote:
> ------------------------------------------------------------------------
>

---

From: Peter Constable <[email-masked]>
Date: Wed, 14 Nov 2007 07:42:35 -0800

Debbie:

I think it might help for the MA to consider the entire issue of exceptional reservations. It is effectively providing something for use in public interchange without fully endorsing it: that's just going to leave people dealing with consuming standards in a quandary, just as we're facing now: they need to interoperate with the publicly-encountered identifier, but they also need to make normative reference to the standard. With exceptional reservations, they end up stuck in a hole with no good way out.

Peter

> From: Debbie Garside [mailto:[email-masked]]
> Sent: Wednesday, November 14, 2007 2:51 AM
> To: [email-masked]
> Cc: 'LTRU Working Group'
> Subject: RE: [Ltru] Re: The "QU" territory/region code
>
> Hi Addison
>

---

From: Peter Constable <[email-masked]>
Date: Wed, 14 Nov 2007 07:48:36 -0800

> with the exception of UK.

Ditto. I'm OK with cherry picking if there's a good reason to, but I don't see this case as having a good reason. And I thought everyone else here wanted to avoid cherry picking altogether.

Peter

---

From: "Debbie Garside" <[email-masked]>
Date: Wed, 14 Nov 2007 15:48:06 -0000

Hi Peter

I agree.  I have broached the subject with ISO Central Secretariat today and
will let you (and LTRU) know of any relevant outcomes.

Best regards

Debbie

> From: Peter Constable [mailto:[email-masked]]
> Sent: 14 November 2007 15:43
> To: [email-masked]; [email-masked]
> Cc: 'LTRU Working Group'
> I think it might help for the MA to consider the entire issue
> of exceptional reservations. It is effectively providing
> something for use in public interchange without fully
> endorsing it: that's just going to leave people dealing with
> consuming standards in a quandary, just as we're facing now:
> they need to interoperate with the publicly-encountered
> identifier, but they also need to make normative reference to
> the standard. With exceptional reservations, they end up
> stuck in a hole with no good way out.
>
>
> Peter
>
>
> > within ISO 3166-1 I would be happy to put forward a proposal to the
> > other MA members.  When writing any proposal please be
> mindful of the
> > criteria for inclusion within ISO 3166-1.  If you can make the
> > proposal fit the inclusion criteria I will present and support it.
> >
> > Best regards
> >
> > Debbie Garside
> >
> >
> propose for
> > > our draft (remember our draft?). Pardon my dust. :-)
> > >
> > > not-very-friendly thread on ietf-languages in which folks mostly
> > > from the software industry attempted (and failed) to register
> > > "es-americas"
> Spanish. The
> > > language, as in "a language recognized by linguistic scholars".
> > > There were, however, some who thought they had a quite
> real need to
> > > identify an artificially created linguistic variant.
> > >
> > > In RFC 4646 we explicitly acknowledged the potential for
> use of the
> > UN
> > > identify an artificial linguistic variant for the EU.
> > > However, I would be unsurprised if, for example, the EC were to
> > > adopt specially controlled language variations for translating EU
> > > "stuff" without having to choose particular local variants (or
> > > translate into all of them).
> > > language" and also not "fr-FR" or "de-DE". This could also be
> > > addressed as "fr-x-euro" or "de-eunion" or some-such.
> > >
> > > What bothers me is the sense that "we" (there is no "we") know
> > > better than the users making the request about their
> application's
> > > needs. I tend to be a little more promiscuous about supporting
> > > variants as a result. There are cases where the thing being
> > > requested isn't well thought out. But I am not altogether
> happy with
> > > the notion that there is only one way to use language
> tags or that
> > > "there is no such language as X hence no use for this subtag in
> > > language tags". We don't actually know that.
> > >
> > > So: I think it would be just grand if 'EU' were actually
> assigned by
> > > ISO
> > > acknowledging the "exceptional reservation" as "an assignment" in
> > > 4646bis. To that end, I'd propose changing Section 2.2.4,
> item 2 in
> > > the list to read:
> > >
> > > --
> > > Standardization, "ISO 3166-1:1997. Codes for the
> representation of
> > > names of countries and their subdivisions -- Part 1:
> Country codes,"
> > > 1997.) ("Codes for the representation of names of countries and
> > > their subdivisions -- Part 1: Country codes") using the list of
> > > alpha-2 country codes, or using assignments subsequently
> made by the
> > > ISO 3166 maintenance agency or governing standardization
> bodies. The
> > > one exception is the code 'EU' (European Union), which is
> > > "exceptionally reserved" for that purpose (but not "assigned") by
> > > ISO 3166.
> > > This code
> > > is assigned in the registry and is subject to the same
> constraints
> > > that appear elsewhere in this document as if it were actually
> > > assigned by ISO 3166.
> > > --
> > >
> > > Regards,
> > >
> > > Addison
> > >
> > > Doug Ewell wrote:
> > > > Both RFC 4646 and draft-4646bis is that they refer to code
> > > > elements "assigned" in ISO 3166-1.  RFC 4645 uses the terms
> > > > "valid" and "assigned" in populating the initial LSR.
> > > > Exceptionally
> > > reserved code
> > > > countries changes with some regularity -- there are currently
> > > > three "official candidate states" and four "potential
> candidates"
> > > -- making
> > > > and the LSR, two countries (if that they are) which
> don't appear
> > > > to exhibit distinct language usage.  In that case, we are
> > > mirroring the

---

From: Peter Constable <[email-masked]>
Date: Wed, 14 Nov 2007 07:53:30 -0800

> ... with the

Actually, it's not cherry picking: it's consistent with the purpose of section 3.4.

Peter

---

From: "Debbie Garside" <[email-masked]>
Date: Wed, 14 Nov 2007 15:55:02 -0000

I would find it useful if anyone has any ideas as to how the MA for ISO
3166-1 could change the way they designate some/all exceptionally reserved
codes.  Obviously, there is a big difference between the reasons for
reserving EU and UK, should we ask the MA to differentiate and would this
help LTRU in devising this standard?  If this is not considered relevant to
this forum (co-chairs?) perhaps members could respond offlist with any ideas
that could be presented to the MA for consideration.

Best regards

Debbie

---

From: Misha Wolf <[email-masked]>
Date: Wed, 14 Nov 2007 15:57:34 +0000

Indeed, ISO 3166 could create a table of codes which are not 
to be assigned because they are widely used synonyms for 
assigned codes.  This table could start with the entry 'UK'.

Misha

-----Original Message-----
From: Debbie Garside [mailto:[email-masked]] 
Sent: 14 November 2007 15:55
To: [email-masked]; [email-masked]
Cc: 'LTRU Working Group'
Subject: RE: [Ltru] Re: The "QU" territory/region code

I would find it useful if anyone has any ideas as to how the MA for ISO
3166-1 could change the way they designate some/all exceptionally
reserved
codes.  Obviously, there is a big difference between the reasons for
reserving EU and UK, should we ask the MA to differentiate and would
this
help LTRU in devising this standard?  If this is not considered relevant
to
this forum (co-chairs?) perhaps members could respond offlist with any
ideas
that could be presented to the MA for consideration.

Best regards

Debbie

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 14 Nov 2007 10:13:28 -0800

I agree with John as well, and Addison's further comments.

Mark

On Nov 14, 2007 7:38 AM, Addison Phillips <[email-masked]> wrote:

> > (International Organization for Standardization, "ISO 3166-1:1997. Codes
> > Part 1: Country codes," 1997.)  ("Codes for the representation of names

---

From: John Cowan <[email-masked]>
Date: Wed, 14 Nov 2007 16:47:11 -0500

Debbie Garside scripsit:

> I would find it useful if anyone has any ideas as to how the MA for
> ISO 3166-1 could change the way they designate some/all exceptionally
> reserved codes.  Obviously, there is a big difference between the
> reasons for reserving EU and UK, should we ask the MA to differentiate
> and would this help LTRU in devising this standard?  If this is not
> considered relevant to this forum (co-chairs?) perhaps members could
> respond offlist with any ideas that could be presented to the MA for
> consideration.

It's important to realize that ISO has tied the 3166/MA's hands pretty
thoroughly -- that's what it means to be a mere Maintenance Agency,
rather than a Registration Authority, which is much more autonomous.
It can't assign a code element to anything except the entities that UNSD
(the United Nations Statistics Division) calls a "country or area".

Since UNSD is chiefly concerned with national and supranational economic
and social statistics, it simply doesn't care very much about the little
islands (okay, Ceuta and Melilla are Spanish "islands" on the mainland of
Africa) and isn't likely to assign code elements for them.  Nor will it
assign two code elements to the U.K.  Assigning a code to the E.U. looks
plausible except that (as many have pointed out) the composition of
the E.U. changes over time, making historical comparisons meaningless.
(When the ancestor of the E.U. began in 1951, it had only six members;
partial precursors go back to 1948 (three members) and 1921 (two members).
Now there are 27, with seven more in candidate or potential-candidate
status.)

So none of these code elements are going to get "assigned" status.
"Exceptionally reserved" is the best we can do, and if we want them we
must live with that.  The questions are:

1) Can we live without them?

2) Can we live with them?

3) If we are going to live with them, what exceptions are needed?

-- 
De plichten van een docent zijn divers,         John Cowan
die van het gehoor ook.                         [email-masked]
      --Edsger Dijkstra                         http://www.ccil.org/~cowan

---

From: Peter Constable <[email-masked]>
Date: Wed, 14 Nov 2007 15:00:19 -0800

> rather than a Registration Authority, which is much more autonomous.

True, but the MA can still report complaints and issues back to TC46. At least from my experience, trying to get feedback through the US TAG into TC46 is a dead end.

Peter

---

From: Martin Duerst <[email-masked]>
Date: Thu, 15 Nov 2007 15:06:32 +0900

At 06:47 07/11/15, John Cowan wrote:

> Assigning a code to the E.U. looks

There are other things that go even further back. For a European
monetary union that worked for quite a while, starting in 1865),
please see http://en.wikipedia.org/wiki/Latin_Monetary_Union.
[at that time, even Switzerland was part of the club :-].

Regards,   Martin.

---

From: Martin Duerst <[email-masked]>
Date: Thu, 15 Nov 2007 15:09:39 +0900

The proposed text, without or (even better) with Misha's improvement,
looks okay to me.

However, I have a concern regarding the future
evolution of "exceptionally reserved" codes. Do new codes go into
the registry straight away? Or should we charge ietf-languages
with making a decision, to weed out examples similar to "UK"?

Regards,    Martin.

At 23:06 07/11/14, John Cowan wrote:
>the IANA registry according to the assignments found in [ISO3166〓1]

---

From: Misha Wolf <[email-masked]>
Date: Thu, 15 Nov 2007 08:01:40 +0000

I suggest that we state that the basis for exclusion is a code being a synonym 
for an existing code, and then quote 'UK' as an example.  Something like:

[...] with the exception of codes which are exact synonyms for assigned codes 
(eg 'UK', which is a synonym for 'GB').

Misha

-----Original Message-----
From: Martin Duerst [mailto:[email-masked]] 
Sent: 15 November 2007 06:10
To: John Cowan; Addison Phillips
Cc: Doug Ewell; LTRU Working Group
Subject: Re: [Ltru] Re: The "QU" territory/region code

Regards,    Martin.

At 23:06 07/11/14, John Cowan wrote:
>John Cowan  http://ccil.org/‾cowan  [email-masked]

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 15 Nov 2007 09:20:11 +0100

> (eg 'UK', which is a synonym for 'GB').

I think DG is a proper subset of IO, and wonder how many languages are spoken
on this military base, apart from en-DG, en-IO, en-GB, and en-US.

All these exceptionally reserved codes are utter dubious for the purpose of
language tags.  Please let Debbie handle the EU issue, not 4646bis.

When I proposed to adopt IANA ccTLDs as reference for 4646 it was rejected,
now you're going to introduce codes that are even more obscure than ccTLDs ?

 Frank

---

From: Peter Constable <[email-masked]>
Date: Thu, 15 Nov 2007 06:23:03 -0800

> with making a decision, to weed out examples similar to "UK"?

Some text can be added to 3.4 to deal with that scenario -- seems to me that's where that belongs.

Peter

---

From: "Debbie Garside" <[email-masked]>
Date: Thu, 15 Nov 2007 15:39:13 -0000

> to identify an artificial linguistic variant for the EU.

In looking at the data surrounding all this, I think we should be careful when 
discussing EU as designated within ISO 3166-1 in the same vein as M.49 codes 
as they are not one and the same; in ISO 3166-1 EU is an exceptionally 
reserved code representing the European Union (with no real distinction over 
time) whereas M.49 represents the region of Europe as 150 (with sub-regions 
also designated).

http://unstats.un.org/unsd/methods/m49/m49regin.htm

http://www.iso.org/iso/support/country_codes/iso_3166_code_lists/iso-3166-1_decoding_table.htm#EU

Best regards

Debbie

> assigned by ISO
> representation of names
> constraints that

---

From: "Debbie Garside" <[email-masked]>
Date: Thu, 15 Nov 2007 15:49:03 -0000

Hi Peter

In looking at the rules governing inclusion of entities within ISO 3166-1, I
think the MA have got it right insofar as they can whilst adhering to the
rules.  By allowing exceptionally reserved codes to be included within the
standard I think they have responded to the needs of industry and users
alike.  As far as I can see, the only other option the MA would have is to
update the standard to allow inclusion of codes that are not included within
UN M.49 (other than as exceptionally reserved); this would need some sort of
criteria design.  There are a number of reasons why this would be a bad
idea, not least is the fact that there are only so many codes left available
for allocation.

As it is, whilst I understand the frustration of LTRU members in this
regard, I am not sure that there is a wise way to move forward on this with
regard to updating ISO 3166-1.

Let me know if you think I am wrong.

Best regards

Debbie

---

From: Peter Constable <[email-masked]>
Date: Thu, 15 Nov 2007 08:53:48 -0800

I could look into this, but perhaps you know: what status do they give to exceptionally-reserved IDs? Is stability the same as for assigned IDs?

Peter

> Sent: Thursday, November 15, 2007 7:49 AM
> To: Peter Constable; [email-masked]
> Cc: 'LTRU Working Group'

---

From: "Debbie Garside" <[email-masked]>
Date: Thu, 15 Nov 2007 20:50:48 -0000

Exceptionally Reserved codes are added at the request of ISO member bodies,
government or international organizations.  It is my belief that the MA
would have to go back to the applicant org if they wanted to change a code
status.  As the status of exceptionally reserved codes states "Code elements
may be used but restrictions may apply" I don't think the MA would
reallocate under any circumstances (bar a 50 year wait as stipulated in the
new standard).

Debbie

> Sent: 15 November 2007 16:54
> I could look into this, but perhaps you know: what status do
> they give to exceptionally-reserved IDs? Is stability the
> same as for assigned IDs?
>
>
> Peter
>
> > In looking at the rules governing inclusion of entities within ISO
> > 3166-1, I think the MA have got it right insofar as they can whilst
> > adhering to the rules.  By allowing exceptionally reserved
> codes to be
> > included within the standard I think they have responded to
> the needs
> > of industry and users alike.  As far as I can see, the only other
> > option the MA would have is to update the standard to allow
> inclusion
> > of codes that are not included within UN M.49 (other than as
> > exceptionally reserved); this would need some sort of
> criteria design.
> > There are a number of reasons why this would be a bad idea,
> not least
> > is the fact that there are only so many codes left available for
> > allocation.
> >
> > regard, I am not sure that there is a wise way to move
> forward on this
> > with regard to updating ISO 3166-1.
> >
> > > I think it might help for the MA to consider the entire issue of
> > > exceptional reservations. It is effectively providing
> something for
> > > use in public interchange without fully endorsing it: that's just
> > > going to leave people dealing with consuming standards in a
> > > quandary, just as we're facing now:
> identifier,
> > > but they also need to make normative reference to the
> standard. With
> > > exceptional reservations, they end up stuck in a hole
> with no good
> > > way out.
> > >
> > >
> > > Peter
> > >
> > >
> > > > I am attending the next meeting of the ISO 3166-1 MA on
> the 31st
> > > > of January
> > > > within ISO 3166-1 I would be happy to put forward a proposal to
> > > > the other MA members.  When writing any proposal please be
> > > mindful of the
> scholars".
> > > > > adopt specially controlled language variations for
> translating
> > > > > EU "stuff" without having to choose particular local variants
> > > > > (or translate into all of them).
> assignment"
> > > > > in 4646bis. To that end, I'd propose changing Section 2.2.4,
> > > item 2 in
> > > > > the list to read:
> > > > >
> > > > > --
> > > > > "exceptionally reserved" for that purpose (but not
> "assigned")
> > > > > by ISO 3166.
> > > > > This code