Message-Id: <6.2.1.2.2.20050722112811.05c9d780@mail.afrac.org>
Date: Fri, 22 Jul 2005 17:21:02 +0200
To: Martin Duerst <duerst@it.aoyama.ac.jp>,
	"Randy Presuhn" <randy_presuhn@mindspring.com>, <ltru@ietf.org>
From: r&d afrac <rd@afrac.org>
Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of theUN
	disclaimer
In-Reply-To: <6.0.0.20.2.20050720180904.07e45b10@itmail.it.aoyama.ac.jp>
References: <6.2.1.2.2.20050719231610.05809220@pop.online.fr>
	<6.0.0.20.2.20050720180904.07e45b10@itmail.it.aoyama.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Dear Martin,
I will try to address this serious mail as seriously as possible. I am on 
vacations with many family things around.

At 03:44 22/07/2005, Martin Duerst wrote:
>[chair hat on]
>Randy is right. "DISCUSS" refers to a very specific part of the process,
>in particular to questions, comments or requests some members of the IESG
>may have on the draft. This is recorded as a "DISCUSS" in the draft tracker
>(see https://datatracker.ietf.org/public/pidtracker.cgi).

We fully agree. The point I rise is a serious point. We are to accept 
external codes and _mix_ them (ISO 3166/UN M.49) in an area sensible to 
every government, except may be the USG. Some pointed out there is no 
Culture Ministry in the USG), and in several English language countries. 
Members of this WG should understand and accept that in some countries 
language is considered as _the_ culture, to the point citizens may consider 
anything concerning their language without their due approval as real a act 
of physical war, in cases calling possibly for personal physical 
retaliation and terror (all the more if they consider it as part of what is 
named "e-colonisation"). We have to take into account this full spectrum of 
understanding of what this WG [mainly composed of English mother tongue 
people] considers. I would underline that the matter of the debates of this 
WG are quite unconceivable in a French speaking environment.

I think this kind of concern is not a concern for a WG. But it is the 
concern of a WG to inform IESG of the problem. What I say (considering the 
Internet standard process spirit/letter) is there are two solutions:

- to propose a text in the hope IESG marks it for DISCUSS.
- to report in the text that the identified problem goes beyond the 
Charter, and that we identified it should be treated somewhere else.

In the first case we run into the risk that our text is accepted and serves 
further on as an IETF position. Out of luck, our proposition could be a 
good one. But it is likely, even if we do our best, it would not be a good 
one as this is a pretty complex one and we are neither lawyers nor 
international diplomats.

The second one is IMHO the most loyal to the IESG. Because the IESG can 
decide to accept our point and mark it for DISCUSS, or disagree with us and 
remove it.

Ideally, the solution would be my reading of the charter: to address all 
the issue through a global framework for the whole internet, truly 
correcting and replacing RFC 3066 and then presenting the ABNF and filters 
of this particular case in a technical RFC.


>The WG is expected to send the draft(s) to the AD and the IESG ***in the best
>possible fashion***, after having done everything they think is necessary.
>If we asa WG come to (rough) consensus that some "political disclaimer" or
>whatever we may call it is necessary, then we should make our best efforts
>to get the best possible text.

See above. This is a solution. This is the one I initially advocated for, 
trying to interest Gov officials, ISO people, Language structures, UNESCO, 
etc. etc. The answer I received from everywhere is "we are not interested 
in this commercial trick, IETF means nothing to us in that area, their 
proposition is absurd and will not fly. Thank you to keep us posted so we 
know where, how and when to kill it".

I think it is not a proper answer. Because it is premature to kill the 
IETF, even if it stays the way it is (RFC 3774). The IETF is also a place 
to protect the technology from all these people: nothing will happen on the 
Internet except through IETF and Open Source and Open Source is not ready 
in terms of network architecture. So I tried to keep an equilibrium, for 
example with the WGIG, which partly follows some of my points.

But there are two main points the WGIG - and this WG - are wrong about:

1. the WGIG places the Internet R&D in private sector, as the WG does in 
mainly relying on Unicode and W3C private commercial consortia. IAB RFC 
3869 clearly says (its "main thesis") that if this is the case the 
architectural R&D of the internet is "in trouble". I can only confirm that: 
I try to keep (at my family expense, as do others on this list or near-by) 
myself near but financially free from Govs and as much as possible 
grassroots and non-profit as I can, for free technical thinking and 
development. This WG only produced a short minded, non scalable, excluding 
solution (I will document this briefly further on).

2. The WGIG (and this WG does not even do that), considers multilingualism 
as DNS and content (this WG excludes DNS what is a grave error, because it 
confuses IETF's IDN mistake with multilingual DNS. Vint Cerf just 
identified that mistake, put the blame on IETF, and calls for work on the 
matter. He starts from phishing which cannot unfortunately be addressed 
without changing the proposition, what will call for a change in the 
architecture of the Internet. So not a little thing.

But the main issue for us as a WG is that language is not the same issue 
when a spoken language for mobiles (reason why mobiles develop far faster 
than the Internet) or when text content for linguists, library and language 
industry. Languages in the IETF must be understood as what IETF considers: 
protocols.

These person to person interintelligibility protocols involve R&D issues 
this WG (financed by commercial interest) has not even alluded to. The 
result is that a Draft about languages identification does not identify 
itself what it considers as a language. I have no objection to the idea of 
standardising the commercial tag of languages, to the contrary. But you do 
not start from the price tag of the members of dominant consortium, as an 
R&D specs for the whole deliverable.

>If some IESG members then think that this
>has to be changed, they will raise a "DISCUSS". But going to the IESG
>with a draft that says something like "IESG, for this section, please
>do the work we were supposed to do" isn't an option.

To do a work we are not supposed, we have not the competence and we have 
not the authority to do is not an option. It would be a error and if we 
make believe it would be a disloyalty. Unless you think you have the 
necessary authority to relate with the IESG liaisons with ISO, IANA, GAC, 
ccTLDs, UNESCO, UN, etc. and actually engage in it. In which case I would 
certainly support you

I will take an example of the difficulty: as a ccTLD (supposed to pay the 
IANA, trustee of a national community, advisor of the Gov - in a country 
where the culture Minister is also the Minister for ICT) and as the 
secretary of an independent intergovernmental, interccTLD, inter-national 
Internet communities think tank, and as a Member of the ccTLD committee for 
the Luxembourg ccTLD meeting, I invited Brian Carpenter to come and 
introduce the way IETF would consider a liaison with ccTLDs. You may recall 
that my call to Greek and Chinese ccTLD Managers on ietf 
-languages@alvestrand.no shown the interest and the political need. Brian's 
answer was roughly (published in my presentation) "I considered with IAB. 
We have nothing to discuss with you. However if there are specific topics, 
please go through ADs" (two Govs I copied the mail asked "what is an AD", 
showing the relational/cultural divide.

Then came the US Statement of principles and then the WGIG, and then Vint 
Cerf which followed in confirming the need and actually supporting my 
proposition to ccTLDs of an INTF. A TF to structure that relation speaking 
user on one side and IETF on the other. And of an UNITRY test bed (along 
ICANN criteria), I am working on, with the support of already a few 
developing/non developing countries.

Our role is not to replace IESG, but our job is not either to fool the IESG.

>If the WG comes to the (rough) consensus that it's better NOT to have a
>"political disclaimer", then we submit a draft without a "political 
>disclaimer".
>If somebody on the IESG thinks that this is a problem, then they will
>raise a "DISCUSS". If the WG and the IESG then can't agree, the IESG
>can request the RFC Editor to attach an "IESG Note" (see e.g.
>http://www.ietf.org/rfc/rfc2251.txt).
>
>Up to this point, everything I have seen from the members of this WG
>strongly indicate that we have (rough) consensus to NOT have a
>"political disclaimer".

This WG is not competent on the matter. For two reasons:
- this is not its charter.
- the consensus is by exhaustion.

Anyway the problem is not the way you, me, IETF sees the things. The 
problem is the way the concerned external parties see them. Inquire by 
yourself.

> >Since you do not want to call a debate on "complement RFC 3066" rather 
> of "replace RFC 3066", and do not want to consider the Charter  issues in 
> the WG, it seems you want them discussed in the brouhaha of the IESG Last Call.
>
>First, it's not sure the IESG Last Call will create a brouhaha.
>Many IESG Last Calls go by without much discussion. This one may,
>or it may not.

This depends essentially on the "complements/replaces"

>Also, as Randy has said (repeatedly), the Charter is up for debate after
>we have done our work. IETF WGs don't start their work by a charter
>debate; if this was ever done in the past, it was abandoned because
>it would be very unproductive.

Here I am lost. I though Randy was using this "after we have done our work" 
as a delaying joke. Now you repeat it, I must consider you say seriously 
that an IETF WG (and this is your intent in this case) is to commonly 
understand the work to achieve in common once that work has been done? This 
is not exactly my own experience of IETF WG, but I am to say that the few I 
shared in have not been successes... This may the reason why?

It rings Alice in Wonderlands to me. But if you say it is the way WG 
proceeds ... I would then be interested in getting a calendar and a 
procedure. When are you going to send a mail with a subject like "let 
understand the work we had to do"?

> >This may give more support to the proposed additions by more 
> legal/political oriented people. I will not oppose this due to the very 
> reduced number of participants to the WG Last Call. But beware that if 
> the document is not mended during the last call, this will probably lead 
> the document to be rejected at some stage (IESG Last Call, IANA, etc.).
>
>If it turns out, during IETF Last Call, that there is a preference for
>a "political disclaimer", and if the WG, the AD, and the IESG agree
>to some kind of wording, such a "political disclaimer" can be added
>at IESG Last Call. In my judgement, this would in no way mean we would
>need to have a second IETF Last Call, or that the IETF Last Call would
>have to fail, because the political language that would be added would
>most probably not change any of the technical provisions of the draft
>nor should it change any other aspects such as registry operation.*

I feel you read me incompletely. I say that the document will fail at some 
stage. If the concerned parties want to pay attention to the IETF (and this 
is my prayer, so we can preserve the Internet standard process credibility 
in the Multilingual field) they will attend the IETF last call and the 
Draft will be killed there (what would be sad, since it could fly as a 
complement). Or it will more likely (I am not going to spend my life 
fighting an ill fitting Draft) be diplomatically killed at IANA level. The 
procedure has been already engaged.

> >As it is, it focuses on an resticted approach, aiming an exclusive for 
> the language industry, against competitive open sources multilingual 
> network oriented propositions and evolutions.
>
>[with my chair hat off]
>It is quite clear that the current draft tries to address the needs of what
>you call the "language industry", because people from this industry came
>forward with actual needs, and worked hard on solutions.

Here is the confusion. Some people of the language industry came forwards 
with this proposition. No the industry. I represent another part (less 
dominant but more pervasive) of this industry. The way they are treated on 
ietf-languages@alvestrand.no or on this WG (as F. Charles was) did not 
pushed them to continue. I commentd already the question of Randy on this 
matter, my response and the support I got.

There are others who worked hard, I would even say harder and have a much 
broader vision and support, you totally disregard. So we agreed (and I 
documented) that we will only proceed outside of this WG - leaving you 
enjoy your format and using the "x-" compatible escape sequence. We think 
it is better to compromise and show usage, running code, etc. demonstrate 
our open position is better, and to expose the bias of the proposed 
exclusion. We got our "no way" excluding response.

This is why, I am probably the only one concerned still considering that 
the proposition of this WG may have merits, if not exclusive and excluding 
(at least to satisfy the part of the industry you refer to). I also think 
that coexistence is far better than opposition.

If I am considered here as the bad guy against the Draft, and outside as 
the bad guy or the traitor defending the Draft ...

>It is in my view completely wrong to claim that the draft is exclusive.
>Indeed, while in RFC 3066, the only way to add language tags was by
>one-by-one registration, and there were no private subtags, the current
>draft is way more flexible and extensible.

I am afraid you miss the point here. RFC 3066 is a wrong solution 
(sometimes named "yellow star" RFC). People were shocked by the timely (was 
it needed, or unfortunate?) registration of Chinese new tags by 
ietf-languages@alvestrand.no (according to the non approved Draft format) 
just before the Yahoo, Microsoft and Google announcement. This lead this 
RFC 3066 Bis to be qualified of a "linguistic Yalta".

1. I note that you say "there were no private subtags", while other says 
1*8alphanum because compatibility with then must be maintained.
2. No one is really interested in the RFC 3066 format and registry, except 
the Unicode consortium people. No problem with that. The proposed system 
"flexibility and extensibility" (I am not convinced of, in your own 
perspective due to the unclear process and ISO relations) is perceived as a 
way to control far more the things than before.

>A recent example was language tags for different school grade levels.
>With RFC3066, you would have had to register en-grade1, en-us-grade1,
>en-gb-grade1, and so on. Now, you could (after some discussion) just
>register grade1 through grade6 (on more), and it could be applied to
>all kinds of languages, wherever it made sense.

Thank you for this example: did you ever consider that "gradeN" is 
meaningless for most outside of your world and that even then, 1 to 6 may 
be meaningless as there may be more grades and in different order? We do 
not want that kind of registry. We want to be ISO 11179 compatible when a 
registry is really to be considered.

> >We only oppose the exclusive, the exclusion and the lack of scalability, 
> flexibility, capacity for innovation and evolution.
>
>Except for purely superficial syntactical issues such as subtag length,...,

"superficial syntactical issues" .... I love it. You will be permitted to 
have every name you want if it is less than 9 characters long, is in ASCII 
and does not include anything else than 0-Z characters. Look how liberal I am?

>I haven't seen any evidence from you (or from others) that the current
>draft lacks scalability, flexibility, extensibility, or capacity for
>innovation.

I suppose you believe it! So I will give you some hint.

"x-1*8alphanum" is supposed to support all the private subtags in a non 
conflicting way. Let consider that one gives every user a different number 
to permit them to differentiate their private subtags. With a billion 
Internet users, we cannot even give a full subtag to all: 9 numerics are 
needed.

Let try to explain people that a cookie name can only be 8alphanum long. 
Try to authenticate a private subtag using an MD5 key, etc.

A full format for a commercial propositions, 8 alphanums for Open Source, 
Networking, etc.

>It would be good if you could document some actual (not superficial)
>cases of how the draft does that. As I said above, there is serious
>evidence in the draft that it actually does the contrary: It greatly
>increases scalability, flexibility, capacity for innovation and
>evolution.

No. It greatly increases scalability, flexibility, capacity for language 
control and evolution reduction to the profit of a dominant part of the 
commercial language tools industry, because of its exclusive.

If the Draft is a complement of RFC 3066 and permits undefined content of 
the "x-tags", permitting every other format to develop and be supported we 
will wind up in a totally acceptable coexistence situation where a 
"xlang:xxx" is an RFC 3066 retro compatible solution and "<x-xxxx> supports 
all the others. It will then be up to the grassroots process to adapt. IMHO 
(this is what I feel could be a possible stabilisation) "x-abc:xxxx" would 
be a good approach where "abc" is a freely used scheme we could relate to 
CRC format names. This means that x-3066:en-Latn-UK could be a legitimate 
format, also entered in places like "xlang:en-Latn-UK".

Obviously, x-tags can support other features the Draft cannot such as 
multilingual entries (via double indexation: entries use a reference number 
documented by multilingual grids), ISO 11179 intended compatibility 
supporting locales, MLDN charsets, referent directories, context additions, 
CRCs, etc. ... and as documented Addison and Mark's Draft with their own 
default format and registry.

jfc


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru