Subject: [Ltru] "Obsolete" region subtags (was: Re: Update to proposed registry)

From: "Doug Ewell" <[email-masked]>
Date: Sun, 13 Mar 2005 17:17:59 -0800

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

> Actually I'm more interested to have some format, whatever it
> is, then pretend that 3066bis existed 1990 or earlier, prove
> that some resulting regional tags would be plain nonsense
> today, and then really _think_ about this part in the draft.

This was something Frank brought up a while back on ietf-languages.
He's concerned about the fact that the draft admits all ISO 3166 codes
ever approved since the inception of that standard (1974), even those
that have since been withdrawn.

He's especially concerned that region subtags such as BQ and NT would be
permanently allocated in the registry to obscure, no-longer-existent
entities, so that if ISO 3166/MA ever reassigns these codes to other
entities, those entities will be stuck with less-mnemonic UN M.49
numeric codes.

IMHO, we should discuss the basic principle of admitting all codes,
instead of quibbling over the merits of individual codes like BQ and NT.
So here is my restatement of Frank's proposal, together with a fair and
unbiased (I hope) set of pro and con arguments:

PROPOSAL:  Remove all ISO 3166 codes withdrawn before a certain date.
Possibilities include 1988-08-15 (publication of ISO 3166 3/e) and
1995-03-01 (publication of RFC 1766).

PRO:  These codes weren't valid in RFC 1766 or 3066, so we should not
have to retroactively allow them now.  They could cause confusion for
users reading the registry.  If ISO 3166/MA does take leave of their
sense and reassign more codes, this limits the damage somewhat.

CON:  Just because an ISO code was withdrawn on a certain date doesn't
mean everyone immediately stopped using it.  Look at the iw/he and ji/yi
examples, where users were *encouraged* to keep generating the old
codes.  Doing this for 3166 but not 639 might attract criticism over
inconsistency.

-Doug Ewell
 Fullerton, California
 http://users.adelphia.net/~dewell/

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

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 14 Mar 2005 03:10:39 +0100

Doug Ewell wrote:

> a fair and unbiased (I hope) set of pro and con arguments:

Yes, within the constraints of the draft.  It's a problem in
the design for some cases:

1 - Region known as XX splits into XX and YY, one part inherits
    the CC.  Old XX tags could be nonsense under the new XX,
    example sl-YU

2 - Regions known as AA and BB join to a new AA, the union
    inherits the CC of one of its former parts.  The registry
    still supports old BB tags, but there's no way to identify
    old AA tags.  Example: dsb-DD vs. fy-DE.

3 - Same case, the registry wouldn't identify AA as canonical
    value for BB, beause it has not the same UN number.
    Example:  YD (720) plus YE (886) are now YE (887).

4 - Sometimes regions have an UN number and no CC, but one or
    more ccTLDs.  Examples:  830 (GG), 830 (JE), 833 (IM).

Almost all "old" problems could be avoided by a cut-off date,
but the same design would soon cause similar "new" problems.

One radical solution could be to admit that some things simply
cannot work "forever", and ISO 3166 CCs belong to this class,

It's like old calendar dates and times.  Maybe the concept of
"regions" for the TZ database is already better than ISO 3166.

Or the UN numbers are the solution, and ISO 3166 CCs and IANA
ccTLDs simply mean whatever they mean "now", allowing old CCs
in their old meaning temporarily (with a canonical UN number),
until they get a new meaning.
                            Bye, Frank

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 14 Mar 2005 02:57:06 +0100

>that have since been withdrawn.

IMHO There is a problem here of who does what.

The IANA most known table, to the point to be referred worldwide as "the 
IANA table" is the ccTLD table which documents the ICANN understanding of 
ISO 3166. Also, as I understand the MoU between IANA, IESG and ICANN this 
table is in the ICANN area of decision (and is quite influenced by GAC). 
Obviously ICANN is not going to wipe off or to create a country at whim. 
But there may be differences and delays. Let for example consider the EU 
case. Recently someone discussed the existence of European Greek vs. Greece 
and Cyprus Greeks. ICANN will give the possibility to document it: is that 
in line with your proposition. Pacific and Indian countries have asked 
similar extensions. What is the situation you want for PS?

At the end of the day we will most probably get the same situation.  But 
the WG-ltru is not the one in control or a second, linguistic, IANA version 
of ISO 3166 is to be created?

Another point to consider. An IETF WG is charter oriented. When the Charter 
is completed, it is closed. My understanding is that the IESG has approved 
this WG for two tasks and a short duration. It can obviously be renewed. 
But I think we should not assumed it to be permanent - at least at this 
stage and without a proper guidance from the IESG.

jfc

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 13 Mar 2005 19:10:47 -0800

JFC (Jefsey) Morfin <jefsey at jefsey dot com> wrote:

> The IANA most known table, to the point to be referred worldwide as
> "the IANA table" is the ccTLD table which documents the ICANN
> understanding of ISO 3166. Also, as I understand the MoU between IANA,
> IESG and ICANN this table is in the ICANN area of decision (and is
> quite influenced by GAC). Obviously ICANN is not going to wipe off or
> to create a country at whim. But there may be differences and delays.
> Let for example consider the EU case. Recently someone discussed the
> existence of European Greek vs. Greece and Cyprus Greeks. ICANN will
> give the possibility to document it: is that in line with your
> proposition. Pacific and Indian countries have asked similar
> extensions. What is the situation you want for PS?

I don't really care what ICANN does.  If the ccTLD table "documents the
ICANN understanding of ISO 3166," their understanding obviously leaves
something to be desired.  They have ccTLDs corresponding to the non-ISO
3166 codes AC, GG, IM, and JE, and they think the code for United
Kingdom is UK instead of GB.

ICANN doesn't need to "give [anyone] the possibility" to document the
various flavors of Greek.  You can write "el" or "el-GR" or "el-CY" or
whatever, right now, according to RFC 3066 or even RFC 1766.

I don't know what PS has to do with the rest of your paragraph, but ISO
3166 has assigned the code PS for "Palestinian Territory, Occupied" and
that is what is relevant here.

> At the end of the day we will most probably get the same situation.
> But the WG-ltru is not the one in control or a second, linguistic,
> IANA version of ISO 3166 is to be created?

I have no idea what is being asked here.

> Another point to consider. An IETF WG is charter oriented. When the
> Charter is completed, it is closed. My understanding is that the IESG
> has approved this WG for two tasks and a short duration. It can
> obviously be renewed. But I think we should not assumed it to be
> permanent - at least at this stage and without a proper guidance from
> the IESG.

I don't think anyone imagines this WG to be permanent.  Both the charter
and the current draft explain that the review function for new subtags
will lie with the ietf-languages list and with the Language Subtag
Reviewer.

-Doug Ewell
 Fullerton, California

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 14 Mar 2005 12:59:12 +0100

At 04:10 14/03/2005, Doug Ewell wrote:
>I don't really care what ICANN does.

Such a lack of care is not appropriate to the current debate.

IANA is to conform to the requirements of this WG only pursuing to the 
terms of the ICANN, IETF, IANA MoU (RFC 2860). For a given period of time, 
ICANN and IANA present the IANA as an ICANN function, so ICANN is actually 
implied twice. This WG Charter does not include a rewrite of this MoU so we 
have to care about what ICANN does, if only to make sure there is no problem.

I call your attention on the part 4 of this MoU and on the possibility of 
ICANN to be confronted to a conflicting position paper or for its BoD to 
take a position on this issue. The last thing this WG should want is to 
face a latter change in the understanding of one of the three used tables.

I note that my position is exactly described in your "And I'm convinced 
that normal Internet users will try to use their ccTLD in language tags no 
matter what RfC 3066bis says. Why not sanction this expected behavior 
instead of trying to forbid it ?".

>If the ccTLD table "documents the ICANN understanding of ISO 3166," their 
>understanding obviously leaves something to be desired.  They have ccTLDs 
>corresponding to the non-ISO 3166 codes AC, GG, IM, and JE, and they think 
>the code for United Kingdom is UK instead of GB.

As you may know, ICANN is advised by the GAC which gathers the documented 
entities (States).  If you notice a discrepancy with ISO 3166 which is also 
sponsored by the same States, I suggest you bring the problem where it 
really belongs: to the UN General Assembly. This is precisely because a 
certain number of problems of same level have been identified that 192 
chiefs of States and States delegations have unanimously voted that a 
report on these issues be presented to the General Secretary. This process 
is currently underway through the WGIG and everyone can contribute.

I think this concern is of real importance and justifies a report. I planed 
to prepare it through a workshop I organize on this issue in June (during 
the EUGENI meeting where most of the concerned organizations and committees 
representatives will be present) after a preparation process which I 
started at the Paris ISO meeting in August.

- I have no problem to invite you (or any other one from the ltru list) 
among my guest speakers (one slot on the 3 or 4 planned slots).
- we can certainly send an earlier letter to Mr. Khummer and to the WGIG to 
call their attention on the issue.

>I have no idea what is being asked here.

Exactly what you say: "the differences are limited to a few odd cases.  And 
we're talking about a future IANA registry here, they already have a 
registry for ccTLDs based on ISO 3166.  I trust that IANA gets it right no 
matter what ISO 3166 does".

This WG can propose a second IANA reading of the ISO 3166.
- one by ICANN as part of its reserved name/numbering area
- one by no-one yet defined to be maintained for the W3C languages needs

But we have to be aware that would probably open the way to other lists 
better satisfying other needs. This conflicts with the RFC 1958 suggestion 
to strive for one single commonly used solution when possible.

>I don't think anyone imagines this WG to be permanent.

Glad you agree.

>Both the charter and the crrent draft explain that the review function for 
>new subtags will lie with the ietf-languages list and with the Language 
>Subtag Reviewer.

The [email-masked] is chartered to review language tags, not to 
review the IANA understanding of ISO tables. This is why I asked for a 
permanent WG-Tags, tagging is not a need limited to languages and just now. 
But better to start with something.

jfc
=====================================================
For your convenience:
Draft: 		http://www.inter-locale.com/ID/draft-ietf-ltru-registry-00.txt
Charter: 	http://ietf.org/html.charters/ltru-charter.html
gmane: 	http://dir.gmane.org/gmane.ietf.ltru
If you were Bcced for information and not familliar with the IETF process:
http://www.ietf.org/rfc/rfc2026.txt
http://www.ietf.org/rfc/rfc2418.txt
http://www.ietf.org/rfc/rfc3934.txt
http://www.ietf.org/rfc/rfc3669.txt
http://www.ietf.org/rfc/rfc3160.txt
http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt
=====================================================
Jon Postel (RFC 1591): "The IANA is not in the business of deciding
what is and what is not a country. The selection of the ISO 3166 list
  as a basis for country code top-level domain names was made with
  the knowledge that ISO has a procedure for determining which
entities should be and should not be on that list."
=====================================================
Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the
same thing, choose one. If a previous design, in the Internet context
or elsewhere, has successfully solved the same problem, choose the
same solution unless there is a good technical reason not to.
Duplication of the same protocol functionality should be avoided as far as
possible, without of course using this argument to reject improvements."
=====================================================
It seems that what works for countries and ISO 3166 since 1978 should
apply to languages and to ISO 693.
=====================================================

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 14 Mar 2005 08:54:36 -0800

> Such a lack of care is not appropriate to the current debate.

I don't care what ICANN does with respect to its interpretation of ISO
3166 country codes as ccTLDs.  They have interpreted them in their own
way (adding a few codes and changing one), and that is fine for them.
UN/ECE has interpreted them in their own way for use in UN/LOCODE
(semi-standardizing the private-use code ZX for offshore installations),
and that is fine for them.

Country codes in language tags are not ccTLDs.  The parties responsible
for ccTLD administration do not influence the use of country codes in
language tags.

> terms of the ICANN, IETF, IANA MoU (RFC 2860). For a given period of
> time, ICANN and IANA present the IANA as an ICANN function, so ICANN
> is actually implied twice. This WG Charter does not include a rewrite
> of this MoU so we have to care about what ICANN does, if only to make
> sure there is no problem.
>
> I call your attention on the part 4 of this MoU and on the possibility
> of ICANN to be confronted to a conflicting position paper or for its
> BoD to take a position on this issue. The last thing this WG should
> want is to face a latter change in the understanding of one of the
> three used tables.

Section 4.1 of RFC 2860 says that it is absolutely within the scope of
IANA to maintain a registry of language tags, or subtags, as long as
there is an RFC calling for them to do so.  Did you have another point?

> I note that my position is exactly described in your "And I'm
> convinced that normal Internet users will try to use their ccTLD in
> language tags no matter what RfC 3066bis says. Why not sanction this
> expected behavior instead of trying to forbid it ?".

I didn't write that, and I don't agree with it.  Frank Ellermann wrote
it.  (The German-style lowercase f in "RfC" is a good clue.)

>> If the ccTLD table "documents the ICANN understanding of ISO 3166,"
>> their understanding obviously leaves something to be desired.  They
>> have ccTLDs corresponding to the non-ISO 3166 codes AC, GG, IM, and
>> JE, and they think the code for United Kingdom is UK instead of GB.
>
> As you may know, ICANN is advised by the GAC which gathers the
> documented entities (States).  If you notice a discrepancy with ISO
> 3166 which is also sponsored by the same States, I suggest you bring
> the problem where it really belongs: to the UN General Assembly. This
> is precisely because a certain number of problems of same level have
> been identified that 192 chiefs of States and States delegations have
> unanimously voted that a report on these issues be presented to the
> General Secretary. This process is currently underway through the WGIG
> and everyone can contribute.

That's nice, but I really don't care how ICANN or IANA chooses to use
ISO 3166 for the purpose of allocating ccTLDs.  It has no bearing on
language tags.

> Exactly what you say: "the differences are limited to a few odd cases.
> And we're talking about a future IANA registry here, they already have
> a registry for ccTLDs based on ISO 3166.  I trust that IANA gets it
> right no matter what ISO 3166 does".

That doesn't sound like me either.  Did I write that?

> But we have to be aware that would probably open the way to other
> lists better satisfying other needs. This conflicts with the RFC 1958
> suggestion to strive for one single commonly used solution when
> possible.

RFC 1958 does not say that one solution has to fit all conceivable
problems.  There is a long, established history of using ISO 3166 codes
(a) for ccTLDs, (b) in language tags, (c) in locale identifiers, and (d)
in other standards and protocols as well.  None of these usages trumps
any other.

> The [email-masked] is chartered to review language tags, not
> to review the IANA understanding of ISO tables. This is why I asked
> for a permanent WG-Tags, tagging is not a need limited to languages
> and just now. But better to start with something.

Two types of subtag requests will be considered by ietf-languages and
approved by the Language Subtag Reviewer:

- those invented by an individual or group
- those based on updates to ISO 639, 3166, or 15924

In the latter case, nobody is asking ietf-languages to "review the IANA
understanding of ISO tables."  The ISO updates will be added *almost*
automatically to the registry.  The only exceptions, described carefully
in the draft, are when ISO codes conflict with something already in the
registry.  No philosophical judgments are required.

-Doug Ewell
 Fullerton, California

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 14 Mar 2005 12:23:47 -0800

Hi -

> From: "JFC (Jefsey) Morfin" <[email-masked]>
> To: "Doug Ewell" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Monday, March 14, 2005 3:59 AM
> Subject: Re: [Ltru] "Obsolete" region subtags (was: Re: Update to proposed registry)
...
> face a latter change in the understanding of one of the three used tables.
...

I really don't see how this is relevant to this WG.  The material cited applies
to the discovery of technical conflicts in the instructions given IANA for the
operation of a given registry.  As long as we provide a non-contradictory spec
for the one registry we are chartered to describe, the cited procedures
will not be invoked.  The fact that parts of some tags may have bit patterns
which might also appear in some other registries is merely a coincidence, as far
as IANA would be concerned, and causes no conflict that would require
invocation of RFC 2860.

Randy

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 15 Mar 2005 02:01:40 +0100

>as IANA would be concerned, and causes no conflict that would require

Dear Randy,
I would not like to harp again and again on the same issue (I fully 
responded already to Martin) wich is the difference between a work among a 
few people and RFCs and the real world which is a little larger and more 
complex and where no one really knows RFCs (so many of them).

I fully understand the interest of some coordination between Unicode, W3C, 
etc. and the political interest to use the simple and central Internet 
standard process for that. But please think of this: what is the use for 
the CLDR project to build a coordinated set of cross references, and to be 
blocked at some later stage by the blunt political "no" I fear. I am into 
this for 27 years. Your effort could be very beneficial if caried well or 
very detrimental otherwise: I have not made my mind yet about it. I am not 
opposed to your quick march, but the risk of mission creep and the 
political oppositions are important and I do not feel you really considered 
them all. An RFC is not a standard. A poor RFC as a BCP 047 replacement 
could kill everything.

So, for the time being, please let us stick to the charter. The charter 
does not say that this WG is to define countries independently from ICANN, 
that is from GAC, that is from their own State. Let stick to KISS. This 
process is on the language identification and internationalization layers. 
You may not share my layered analysis of the Multilingual Internet, but 
these layers do exist and if you venture into Country and Language 
definition you will be blocked sometime.

IMHO all this needs adherence. I do not see it yet. Let build it together.
jfc

---

From: "Jon Hanna" <[email-masked]>
Date: Tue, 15 Mar 2005 01:11:32 -0000

> I would not like to harp again and again on the same issue

Great so.

Regards,
Jon Hanna
Work: <http://www.selkieweb.com/>
Play: <http://www.hackcraft.net/>
Chat: <irc://irc.freenode.net/selkie>

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 15 Mar 2005 03:56:27 +0100

> At 04:10 14/03/2005, Doug Ewell wrote:
[...]
> I note that my position is exactly described in your
[...]

That wasn't Doug, it was me in another article, and Doug only
answered it in another article, please don't confuse this.

> I suggest you bring the problem where it really belongs: to
> the UN General Assembly.

Now wait a moment, I know that UK is no country code and only
a ccTLD, just like everybody else here on this list.  We don't
need the UN for this "problem".  We can only decide to use IANA
as source (indirectly almost the same as ISO 3166), or we use
ISO 3166 directly.  For "we" read:  the future tag reviewer.

"We" could also mix these strategies, accept all ccTLDs (= be
liberal in what you accept), but generate only the official
CCs.  There's no best way to do it, supporting UK is horrible,
but not supporting IM is also a pain.

                         Bye, Frank

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 15 Mar 2005 12:28:36 +0100

>answered it in another article, please don't confuse this.

Dear Frank,
Apologies. The point was well made anyway.

>a ccTLD, just like everybody else here on this list.

This is not fully exact, and this is the point.

>We don't need the UN for this "problem".  We can only decide to use IANA 
>as source (indirectly almost the same as ISO 3166), or we use ISO 3166 
>directly.  For "we" read:  the future tag reviewer.

I am afraid you can, but you will be blocked if this is not what the 
British Government wants (they are the one who accepted UK, GG, JJ, IM.. 
through ICANN, and GB through ISO).

You cannot _decide_ to use the IANA or ISO source. You can propose an RFC, 
but again the one who will decide (as for any RFC) is the market, and this 
market in this case starts with the Governments who made their point load 
and clear (WSIS) and who may say it at GAC level.

What I try to make understood is that the document this WG will produce 
will be counterproductive if it is not supported by the entities in charge 
(Governments) and their usual delegates (GAC, national NICs, Culture 
Ministries, Academic and Computer people), their common bodies (ISO, ITU, 
UNESCO, WSIS) and their national users. Worst, if it is opposed.

>but not supporting IM is also a pain.

We should stop talking about ccTLDs. They blur the picture. We are talking 
of country codes and of local Internet communities, of people. These people 
have a Government to represent them. We do not represent them. We are 
simply to serve them the way they want. If we do not do that we will lose 
them and we will lose our credibility as a global system, what means we 
could close the shop.

To help us understand how we stand. When referring to a network issue we 
often think of hierarchies. This is the root (:-) of most of our 
misunderstandings. Network, and the real world you propose something to 
(such as this Draft), are not hierarchical (centralized) and ruled by 
RFCs.They are not even decentralized (meshed top like in the DNS, with 
local hierarchy) with some opinion leaders to convice. Real life networking 
is granular and distributed. DNS is just a default hierarchical vision of 
the universal namespace. As are the CLDR proposed locales.

As soon as you accept this, you see you can support whatever people want, 
without any big problem (may be some challenges :-), and everyone will 
support you. But I accept it may change a few things, not my fault: see 
Paul Bahan.

jfc

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 16 Mar 2005 13:52:47 +0100

JFC (Jefsey) Morfin wrote:

> you will be blocked if this is not what the British
> Government wants (they are the one who accepted UK, GG, JJ,
> IM..through ICANN, and GB through ISO).

Don't forget AC.  My best guess is that somebody talked faster
than Jon Postel could think, and that's why we have AC and UK
today.  What has the British government to do with IM and the
Channel Islands ?  AFAIK they don't belong to the EU, they are
no part of the UK, and they are no part of the British Empire
like GI or SH (incl. AC, but far away from SH).  Maybe I'm
wrong, and the "Duchy of Normandy" story is only a fairy tale.

> You cannot _decide_ to use the IANA or ISO source.

This WG can decide that the language tag reviewer should create
region codes as he sees fit.  It would fail in the "last call",
because nobody would volunteer as a tag reviewer in this case,
unless he's suicidal.  But in theory the WG could propose this.

> this market in this case starts with the Governments

Governments have _nothing_ to do with language tags, that's a
feature and no bug.  I'm not planning to discuss ku-TR with
the government of TR, and I also refuse to discuss mnc-TW (?)
with the government of CN.  In many cases languages are _not_
recognized by the corresponding regional governments.

> What I try to make understood is that the document this WG
> will produce will be counterproductive if it is not supported
> by the entities in charge (Governments)

I'm strongly opposed to this position.  Governments are among
the last entities I'd trust, and only after a random generator
failed.
         Bye, Frank

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 16 Mar 2005 16:19:22 +0100

Dear Frank,
I understand and respect your political positions.
What I do not understand then is why do you want to use the IANA?
As you may know, the IANA is an US Governement set of functions contracted 
to ICANN.
http://www.icann.org/general/iana-contract-09feb00.htm
http://www.icann.org/general/iana-contract-21mar01.htm
http://www.icann.org/general/iana-contract-17mar03.htm

>the last entities I'd trust, and only after a random generator

More generaly you may want to consult:
http://www.icann.org/general/agreements.htm
to understand in which environment the IANA functions.

The MoU with IETF stipulates that:
"4.3. Two particular assigned spaces present policy issues in addition to 
the technical considerations specified by the IETF: the assignment of 
domain names, and the assignment of IP address blocks. These policy issues 
are outside the scope of this MOU.

Note that (a) assignments of domain names for technical uses (such as 
domain names for inverse DNS lookup), (b) assignments of specialised 
address blocks (such as multicast or anycast blocks), and (c) experimental 
assignments are not considered to be policy issues, and shall remain 
subject to the provisions of this Section 4. (For purposes of this MOU, the 
term "assignments" includes allocations.) In the event ICANN adopts a 
policy that prevents it from complying with the provisions of this Section 
4 with respect to the assignments described in (a) - (c) above, ICANN will 
notify the IETF, which may then exercise its ability to cancel this MOU 
under Section 2 above.
"
What is discussed here is "in the event ICANN adopts a policy ....". I 
submit that what is relevant to IDNs does not fall under the terms of this 
agreement. I submit that what is true for ICANN adopting a policy .... is 
also true in the case IETF introduces discrepancies with ICANN policies 
(your abrupt wording concerning some of the ccTLDs is an obvious 
discrepancy). I submit that this wording can only confort the USG, ICANN, 
the GAC, UNESCO, ITU to consider that the name IANA area extends to 
language issues. A position I certainly support, extending it to Civil 
Society co-control.

This is why I suggest that instead in saying "I do what I want", we try to 
coordinate, look for syngergy in the others' need we could address at the 
same time, to obtain a better entertwinned and therefore mutually protected 
situation.

jfc

Hosting a registry will cost you probably $ 250, all included.
And as a premium, I would support anything you may want to do.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 17 Mar 2005 05:42:06 +0100

JFC (Jefsey) Morfin wrote:

> why do you want to use the IANA?

I'm not exactly sure why, but at the moment I trust that they
try to work for some common good.  I never had any problems
with ICANN, quite the contrary, I like their WDPRS among other
things.  That's all off topic here, let's stick to the facts,
at the moment IANA hosts all registries related to RfCs.

In theory it might be possible to organize this in another way,
with a registry at the W3C, an Unicode TR, or an ECMA standard.
But why ?  IANA will do what the language tag reviewer says, as
long as he follows the rules in the future 3066bis.

ICANN won't get (let alone follow) orders by an US government
to unlist "haw", that's bad science fiction.  And if ICANN is
dissolved somebody else would volunteer as the new IANA.  Not
<http://iana.netnod.se/>, that server is apparently down today,
but maybe ORSN or OCLC or W3C or Unicode etc.  Bye, Frank

---

From: Martin Duerst <[email-masked]>
Date: Thu, 17 Mar 2005 14:29:27 +0900

RFC 1766 and RFC 3066 haven't had either much support or much
opposition from governements and related organizations.
My understanding is that this was because they did the job
they were designed to do reasonably well.

What makes you think that for the update we are currently working on,
this will be different? My assumption is that if we produce something
that does it's job reasonably well, people (individuals, governements,
companies,...) will just use it.

If there is anybody out there that does not trust us to do a reasonable
job, the best thing for them is to join and help us do better.

If somebody isn't joining, then the details that we work on are probably
just not important enough to them, and they are ready to use whatever
we produce, in the same way they have been fine with previous RFCs.

Regards,   Martin.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 17 Mar 2005 12:29:00 +0100

On 06:29 17/03/2005, Martin Duerst said:
> will be counterproductive if it is not supported by the entities in 
> charge (Governments) and their usual delegates (GAC, national NICs, 
> Culture Ministries, Academic and Computer people), their common bodies 
> (ISO, ITU, UNESCO, WSIS) and their national users. Worst, if it is opposed.

Dear Martin,
we probably disagree/agree on minor points IRT ccTLD, etc. But this is not 
a major issue. The market will decide. I did not sleep this night. It is 
noon and I am tired. I will however try to make you understand. Excuse me 
if this is not perfect.

>they were designed to do reasonably well.

Let drop all the RFC introduction confusion adding verbs to verbs. Their 
real job is to permit qualify language related issues and text as belonging 
to a language. The interest of the IDN Tables is that it is a (only?) 
application within the IANA.

It target is to get a text in French and to describe it as fr-Latn-FR so 
everyone understand what it is. Great.
The langtag is used to qualify/name the language of a text.

>companies,...) will just use it.

If this was still the same, yes. This is why we were several to say no 
problem with the Draft should it be used in the same way as 3066. But 
actually the reason why RFC 3066 has no problem it is because it is not 
applied.

- the ietf-languages list is an unknown list with no exposure and it did 
not registered much tags. The intent is to change that and to support every 
language with a registered tag. Associating in the IANA tables language 
names, countries, registrants and documentation for all of them. Look at 
the situation of the wikipedia on a certain number of languages and you 
will understand the change. This is why this list must get the proper 
exposure, to get acknowledged experts from every languages, familiar with 
the network technology and their national situation and policy. This way no 
one will be able to object the system is biased and a State sovereignty 
violation.

- the RFC 3066 describes a lot of applications which are quoted the same in 
the draft. But these applications are not used. This changes with the new 
formalization and exposure. Quoted applications such as word processors, 
grammar checker, etc will be really considered.

Big difference,  they are no more read-only/qualify, they are write and 
produce.

Let say there is a Greek text and I start editing it in French and I keep 
the Greek langtag. How will you be able to say I am wrong? I will say "this 
is Greek". To prove me wrong you need a reference to be run against my 
text, a syntax, a semantic, a grammar, a dictionary, etc. Short of that you 
may know that my text is not Greek, but you cannot do anything more. You 
need two additional descriptors to do that: an authoritative reference you 
can oppose me or force me to apply, and you need a style to say how you 
want me to apply it.

There may be other descriptors needed, but Word uses only these 5 
descriptors and my analysis says the same. You may say "I describe and I do 
not know where to document your additional descriptors from (may be style, 
but not reference, in most of the cases)". I say "you define and if you 
define with 3 descriptors this only it means you use defaults". The entire 
world will understand the defaults are the version of the langtag 
registrant. IBM, Microsoft, Apple. This is unthinkable.

So there are two things to do here:

1. to reduce/keep the additonal registrations of subtags identical to the 
concerned ISO list. There should be no reference to a registrant, nor to 
additional elements. This should be reserved to the review process. The 
registration should be bilingual when ISO is bilingual (for the same two 
different sources of study). They should be concerted with the ISO reviewer 
who may have good reasons why not to have it. There should be several 
elected reviewers, otherwise the pressure will be to much. Look a the way 
Michael reacted to my friendly pressure. Others will be tough.

2. let define that the language tag uses 5 main descriptors which can be 
reduced to 1, 2, 3 or more when qualifying and having to be 5 when defining.

Otherwise it would be analyse flaw. This would only lead States to block 
the issue at the IANA. States go slowly. They take time to understand and 
to decide. So, they may take one to three years. But they will definitely 
block what they will consider as a major violation of their cultural 
sovereignty. They are here to protect us, and they will carry their job.

>job, the best thing for them is to join and help us do better.

Thx! It happens that this is why I am here. And I keep reporting.

It happens that the world is not at the order of the IESG and interested in 
sharing in the IETF. They have several way to help. This year 
through  through the WSIS (I know IETF is not interested), then the GAC (I 
know IETF is interested in ICANN only when they obey the RFCs), then the 
ITU (I know IETF does not want to relate with them). This does not make 
things easy.

You have to also understand, that in September the IAB has sent an RFC to 
the States asking their money to fund Internet R&D. This RFC does not 
allude to languages. So, States deduced that IETF is not interested. Then, 
some said this is not true, this RFC was only intended for the US 
Government. It was not necessarily a good move.

>we produce, in the same way they have been fine with previous RFCs.

Do you really believe this?

All this Unicode people effort is of interest. The analysis should be 
completed, some warranties worked out and it should be sold to everyone 
concerned. Namely a few key Governments, International institutions, etc. 
And to be demonstrated, reported, documented. Support obtained from OS 
developers, national Linux communities.

Otherwise it cannot fly. It can take-off. But it will not fly. You are 
touching culture at the core!
Or present something no one can object and sell it around asking everyone 
"do you object to something?". Once you have 40 ccTLDs (local communities), 
30 main governments supporting it, start a pilot process. Keep reporting. 
There is no big problem in getting through, if done the proper way with the 
proper logic.

jfc

---

From: John Cowan <[email-masked]>
Date: Thu, 17 Mar 2005 09:23:54 -0500

> The langtag is used to qualify/name the language of a text.

That is indeed the purpose of language tags.

> actually the reason why RFC 3066 has no problem it is because it is not 

RFC 3066 is indeed applied, and in many places.  Wherever you see
an Accept-Language header in HTTP, or a lang attribute in HTML, or
an xml:lang attribute in XML, RFC 3066 is being applied.

> not registered much tags. The intent is to change that and to support 
> every language with a registered tag. Associating in the IANA tables 
> language names, countries, registrants and documentation for all of them. 

Most of this is just a clone of ISO 639 and ISO 3166.  Under the new
draft, it will be much less necessary to register new and unique subtags.

> Look at the situation of the wikipedia on a certain number of languages 
> and you will understand the change. This is why this list must get the 
> proper exposure, to get acknowledged experts from every languages, 
> familiar with the network technology and their national situation and 
> policy. This way no one will be able to object the system is biased and a 
> State sovereignty violation.

This concern is overblown.  Languages are not the property of states.
Nor is it plausible that experts in the world's 7000 languages are going
to also be familiar with "network technology" (whatever that means
exactly).

It is more or less an accident that language tags are an IETF issue
at all, as their connection to the Internet as such is rather weak.
But here we are.

> - the RFC 3066 describes a lot of applications which are quoted the same 
> in the draft. But these applications are not used. This changes with the 
> new formalization and exposure. Quoted applications such as word 
> processors, grammar checker, etc will be really considered.

They are in use today.

> the Greek langtag. How will you be able to say I am wrong? I will say 
> "this is Greek". To prove me wrong you need a reference to be run against 
> my text, a syntax, a semantic, a grammar, a dictionary, etc. Short of 
> that you may know that my text is not Greek, but you cannot do anything 
> more. You need two additional descriptors to do that: an authoritative 
> reference you can oppose me or force me to apply, and you need a style to 
> say how you want me to apply it.

This concern is also overblown.  There is simply no dispute in general
about what is Greek and what is French, any more than there is serious
confusion between frogs and pond ripples (although a frog can be seen
as a wave and a ripple as a particle from a quantum-mechanical viewpoint).

> concerned ISO list.

The ISO 639 list is known to inadequately identify the languages on it;
Peter Constable and others have done heroic work in attempting to
clarify this in order to create the current editor's draft of 639-3
(which will by intention provide a code for every language).

> There should be no reference to a registrant, nor to 
> different sources of study). 

The registrant is tracked for purely administrative reasons, not because
he or she is considered to be individually authoritative.

> reduced to 1, 2, 3 or more when qualifying and having to be 5 when 

This concern too is overblown.  There are a very, very few cases where
language identification is political:  "This text is Croatian."  "No, it
is Serbian."  For the overwhelming majority of languages, there is
no dispute about identity.  (There are often disputes over what is a
language per se and what is a language variety, but that is not an
essential concern for RFC 3066 any more than the analogous concern
over states vs. territories is for ISO 3166.)

-- 
John Cowan  www.ccil.org/~cowan  [email-masked]  www.reutershealth.com
Monday we watch-a Firefly's house, but he no come out.  He wasn't home.
Tuesday we go to the ball game, but he fool us.  He no show up.  Wednesday he
go to the ball game, and we fool him.  We no show up.  Thursday was a
double-header.  Nobody show up.  Friday it rained all day.  There was no ball
game, so we stayed home and we listened to it on-a the radio.  --Chicolini

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 17 Mar 2005 22:13:50 -0800

Hi -

> From: "Frank Ellermann" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, March 16, 2005 8:42 PM
> Subject: [Ltru] Registry homepage (was: "Obsolete" region subtags)
>

...

There's a simpler answer.  Our charter says that this WG is to
"describe the structure of the IANA registry."  Alternatives are
outside the scope of this working group.

Please, let's focus this energy on the work we were chartered to do.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 18 Mar 2005 14:53:22 -0800

Hi -

(Co-chair hat mostly on)

> Return-Path: <[email-masked]>
> Message-Id: <[email-masked]>
> X-Sender: [email-masked]
> X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
> Date: Fri, 18 Mar 2005 12:13:50 +0100
> To: "Randy Presuhn" <[email-masked]>
> Subject: Re: [Ltru] Registry homepage (was: "Obsolete" region subtags)
> Cc: "LTRU Working Group" <[email-masked]>

PLEASE don't CC people when you know they are subscribed to the WG
mailing list.  We get too much email as it is.  This comment is directed at
*several* active participants on this list, not just JFC.

...
> Dont' you agree that our job is to discuss an answer to a charter which
> only assigns us to define the "structure of the IANA registry"? An
> XML/ASN.1 structure.

No.  This is not the time to discuss changes to the charter.
After the WG has completed its work, we can go into the
re-charter / shutdown discussion.

> When IESG does that it is because they want to be very restrictive or not
> to limit the scope of the debate.

The latter has never been my experience in the IETF.
The latter interpretation might be more defensible in the IRTF,
but this is not the IRTF.

> My reading is the second one due to the
> charter last paragraph which implies that we have to revamp of the review
> process.

I do not follow your reasoning.  Are we reading the same document?
The last paragraph of the charter states:

| This working group will not take over the existing review function of
| the ietf-languages list. The ietf-languages list will continue to
| review tags according to RFC 3066 until the first document produced by
| the WG is approved by the IESG for publication as an RFC. Then it will
| review according to whatever procedures the first document specifies.

This paragraph limits the scope of the WG's activity and discussion.  I do
not see how it can be interpreted as supporting the claim that the IESG did
not want to limit the scope of the debate.

> Many other important questions are not listed.

Of course.  Many important issues are out of scope for this WG.
E.g.: Why did my forsythias bloom so late this year, while my apple
trees bloomed early?

> How to define the technical role of the IANA in area?

As others have explained, IANA does the clerical work.

> Will it be a repository, a  clearinghouse, a registry.

This working group is called "Language Tag Registry Update",
so I guess "registry" would be a safe bet.  :-)

> Will it act as only a web pages, as a
> "whatidiom" web service, as an FTP server?

Out of scope.

> How is it to be organized? What
> is the contingency plan if it changes (this has to do with the adressing of
> the bases which can be hard coded in millions of programs), the NIC changed
> a few time since it was created. etc.

Although this is out of scope, you might benefit from reading
http://www.ietf.org/internet-drafts/draft-ietf-grow-embed-addr-05.txt

> The first question to consider is what is this structure in that registry
> going to do for who. There are three classes of people involved:
>
> - those who manage the structure - IANA with an important backlog (if Frank
> is correct): question is why? How can our solution help? And there are many
> technical solutions to that I am surprised no one considers.

Out of scope.

> - those who fill the data into the structure (among who is Frank, with
> seemingly some feelings and misunderstandings). It is important to
> determine the procedure, the guidance, etc. soi they feel at ease and
> motivated. Some are voluntaries, some are employees of organizations with
> social, cultural, religious or commercial interests, some are civil
> servants. Some are linguists, some are network people. We need to keep a
> balance in the best common interest. Frank is in that sense a good
> representative of possible feelings (good or bad) we must take into
> account.

The *procedures* for registration are at the heart of our charter.
Although the usability of the procedures we define is important to
consider, the mix of people who ultimately make use of the procedures
is not our concern.  The experience of those who have used the existing
procedures should be our guide here, in my opinion.

> Another aspect is the role of the ietf-language list and of its
> procedures which is depend on all of this.

The charter is crystal clear:

| The ietf-languages list will continue to
| review tags according to RFC 3066 until the first document produced by
| the WG is approved by the IESG for publication as an RFC. Then it will
| review according to whatever procedures the first document specifies.

> - those who will use it. I represent some of them.

Participation in the IETF is by *individuals*, not representatives.

> All together we need something which will work.

Agreed.

...

Annoyingly long signature deleted.

Randy