Subject: RE: [Ltru] please, get real!

From: "Addison Phillips" <[email-masked]>
Date: Thu, 7 Jul 2005 08:00:21 -0700

To remove the RFC 3066 registry from IANA would require a new RFC, such as we are working on here, so...

Where do you propose to put the registry if not IANA? A proposal to host it somewhere else should include the "somewhere else".

For the remainder of the issues in your note below, obviously no one on this list is going to convince you to change your position and at least a number of us are not going to change our positions (that we have done the right things with the draft). I suggest we agree to disagree and move along in the process.

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of r&d afrac
> Sent: 2005?7?7? 6:46
> To: [email-masked]
> Subject: [Ltru] please, get real!
> 
> I have been challenged privately to explain publicly why I wanted to see
> the RFC 3066 Registry removed from the IANA. I suppose this is just
> another
> troll, but I think the point important enough to explain it however
> obvious, challenged or not.
> 
> A debate goes on, on the IETF main list, to know if IESG was entitled to
> refuse a code point to Dr. Lawrence Robert. This permits some to follow on
> 25 years old feuds, or to come back on old RFCs, or to propose changes to
> RFC 2860, as if it was not the result on a negotiation where the other
> partner is now confirmed as the US Government. What is important to us, is
> to observe that the political layer is quickly reached when a registry
> manager is considered as a Judge and not as a simple registration
> collector.
> 
> - I proposed the Registry to act as a smart recorder: everything is
> accepted except if consensually opposed on the opinion of the reviewer.
> This would reduce the risks of contention and speed-up the process.
> 
> - The concerns remains high with the documentation of issues subject to
> national policies. Let say that I want to register en-Latn-US and
> I  describe the language with a reference to an American translation of a
> French Cook Book (we all know that I could give much poorer examples).
> What
> would be the response?
> 
> But in using ISO 3166, we enter political langtags. Even a simple national
> map, a nation's name are political. So, languages....
> 
> If you consider the following:
> http://news.yahoo.com/s/afp/20050613/tc_afp/chinainternetcompanymicrosoft;
> _ylt=AsL7orP4gnws5tkilESYvF0jtBAF;_ylu=X3oDMTBiMW04NW9mBHNlYwMlJVRPUCUl
> the permitted pages will necessarily be stamped. This is no different from
> Kentucky press as a concept. This is a language with a referent similar to
> anyEnglish referent but with some terms contextually removed. Necessarily
> at some stage, librarian, press, readers, on-line archives, etc. will want
> to classify the pages using that filtered language. Our role is not to
> judge but to enable: we need to support it (and it is probably good to
> expose it).
> 
> But, frankly, is it to IETF (or even ICANN), and to Michael Everson to
> sponsor such a registration? To IANA to broadcast it under the approval of
> IESG? I do not think so. I say that such a problem for the IANA, ICANN and
> everyone, mainly comes from the form of RFC 3066 registration described by
> the Draft. The Internet Community should be mature enough to identify and
> address the problem. To do that it trusts this WG.
> 
> Please, get real!
> jfc
> 
> PS. I suspect that now a friend/avatar(?) of my challenger will ask that I
> am expelled because I rise the proper questions. I mention this because I
> am tired of this personal teasing and I wish it to stop. If you people are
> so aware of this debate, why not to join the WG-ltru? Or may you are on it
> (I do not know all the 57 members of the list).
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

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

---

From: r&d afrac <[email-masked]>
Date: Fri, 08 Jul 2005 02:10:00 +0200

Dear Addison,

>we are working on here, so...

Yes. This what I am talking about. As explained, RFC 2860 is an MoU between 
ICANN, IANA and IETF. This MoU is in limbo because no one knows if ICANN 
still has the capacity to sign it. Legally speaking the IANA is an USG 
property, contracted on a yearly basis to ICANN. There are serious legal 
considerations about the right of the USG to give it away without a Bill 
(General Accounting Office, Congress). The USG said they did not want to 
give it away nor probably to continue to lease it, but to keep it - ICANN 
assisting. This is up to the ICANN lawyers to see into it and USG to 
explain/negotiate at the WSIS. The key links are under 
http://nicso.org/iana.htm

I document the reason why for four years. I ran a two year test bed 
including it and started the AFRAC exploration under public and private 
interests supervision: there is no way USA security and identity can be run 
by foreign undetermined interests, no more than France security and 
identity can be run by the USA or lose foreign undetermined interests. And 
the same is true for every other nation and culture (look at Tamils).

The US position was triggered by the Internet balkanisation (and USA adds 
to it) which results from the IETF IDN propositions and from this Draft. It 
lead to a DNS split because IDNs are not accepted (already three non legacy 
TLDs resolving in the top zone). It will lead to a IANA split, this Draft 
being the trigger, by countries and cultures not accepting to be subject to 
an US Registry nor to foreign decisions, appreciations, definitions, 
correlations other than the one they accepted/decided through ISO.

The immediate solution of compromise I propose is simple: that ISO 3166 and 
ISO 639 issues are understood as "name and numbers" issues and are 
therefore temporarily put into the ICANN part of the IANA (cf. RFC 2860), 
under the control of the GAC. This will permit countries to be involved 
when their ISO 3166 code is affected. Then to remove that Registry from the 
US IANA, to transfer a copy of it to the ICANN Common Reference Center, as 
well as to AFRAC and other national CRCs round the world, under an ISO 
11179 commonly designed intergovernance.

Other solutions will probably be discussed in different fora (as suggested 
by the US Statement of Principles). I do not expect this to be seriously 
addressed before the Tunis meeting. But preparation has started.

>For the remainder of the issues in your note below, obviously no one on 
>this list is going to convince you to change your position and at least a 
>number of us are not going to change our positions (that we have done the 
>right things with the draft). I suggest we agree to disagree and move 
>along in the process.

Unfortunately this is not possible. As I indicated it many times: I only 
object one word in your document ("replace RFC 3066" instead of "complement 
RFC 3066") but it makes that I cannot give up and that your Draft cannot be 
accepted.

Or split your Drafts in another way: what is generic for the Registry 
management in terms of metamodel in a BCP 47, and regroup everything which 
concerns your particular format and its filters in the second document.

Please understand your choice:

- either you want a US Registry, by a US IANA managed by a US ICANN (this 
is the US Statement of Principles, the US law and the increasing 
international understanding ). Do not expect a return to the position ante: 
because everything is based on trust. No one would trust the US if they 
changed their mind again. Also the US attitude is the correct one: all the 
other Govs share the obligation to do the same and the USA said they will 
help. This has a name "digital umbrella", if you add culture to it, it is 
"e-colonisation"; the counter proposition is partition if organised, 
balkanisation otherwise. My own proposition is compartmentalisation, for 
risks and interference containment, but network continuity. CRCs are a key 
element of the needed network new granularity. We created AFRAC for that.

- or you ultimately want a global distributed register for the whole 
internet (all the transitions are possible). I will then be involved since 
I am the only one having worked for four years on its preparation, having a 
team and ties assisting it, being on the board of organisations which will 
be influent there, specifying and planning to have a working server by 
September, etc.. If I am in this WG it is to gain the best knowledge of the 
Registry Language issue and Multilingual Internet, and to find the best 
solution for all through an RFC or a WSIS declaration. I think this should 
be also your target. What is sad is that I will have a running code, while 
you will still be blocked by a one single word.

The IANA/ICANN situation where a single person could decide about a 
worldwide IANA registry under the control of a few allies is coming to an 
end. I cannot document what will be the short term future because we start 
discussing it, and that the people involved are not necessarily those who 
used to be involved up to now. But I expect that by Septembre/Novembre we 
will know far better, technically and politically. I can however tell you 
from the past that this should go quickly enough (one or two years) once 
States becomes involved.

I think I cannot be clearer?
jfc

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 7 Jul 2005 18:09:02 -0700

Hi -

> From: "r&d afrac" <[email-masked]>
> To: "Addison Phillips" <[email-masked]>; <[email-masked]>
> Sent: Thursday, July 07, 2005 5:10 PM
> Subject: RE: [Ltru] please, get real!
...
> 11179 commonly designed intergovernance.

This discussion does not belong here.  The administration of ISO 3166 and
ISO 639 by definition belongs to ISO, and the ltru WG in the IETF is not ISO.

...
> RFC 3066") but it makes that I cannot give up and that your Draft cannot be

This is what we in the IETF call a "non-starter".
The working group charter is abundantly clear in directing us to produce
"a successor to RFC 3066".  Not a "complement".  A successor.

> concerns your particular format and its filters in the second document.
...

This is not what we were chartered to do.  We were chartered to produce
two documents: the first is "a successor to RFC 3066"  and the second
document will "describe matching algorithms".  The mechanics of populating
the registry required a third document, but the ADs saw this as not requiring
a charter update.

Randy, ltru co-chair