Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of the UN disclaimer

From: r&d afrac <[email-masked]>
Date: Tue, 19 Jul 2005 23:34:39 +0200

At 01:58 19/07/2005, Randy Presuhn wrote:
>Hi -
> > The Draft is intended to be published, so this wording cannot be in the
> > IANA section only. May be a simple solution would be to enter mentions to
> > the Editors (who ever they will be at whatever technical, legal, political
> > level) under the form "[the WG thinks there might be a text needed here to
> > possibly address the following concerns by the IETF liaison with, the IASA
> > lawyers, the IANA lawyers, ICANN, GAC]".
>...
>
>That's not how the process works.  What a working group hands to the IESG
>is what that working group would like to see published as an RFC, with only
>those formatting changes needed to account for the difference between
>i-d and RFC formats.  Routinely, references will be updated and typos fixed.
>The IESG may "DISCUSS" the document with the WG, which may result
>in subsequent edits, as may the IETF last call.  If necessary, an updated
>i-d will be handed to the RFC editor.  When publication time arrives, there is
>the AUTH48 period during which the RFC editor verifies with the document's
>editor that nothing has been broken by formatting changes, etc.  Documents'
>editors rarely change during this entire process.

Sorry, but please reread what you wrote. "The IESG may "DISCUSS" the 
document with the WG". In marking ourself the text for discussion witht the 
WG we force that discussion. The WG has no liaison with the concerned 
bodies. IESG has.

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. 
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.). 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. Except through the reduced capacity 
of the DISCUSS (now precisely under discussion) there is no more 
flexibility. You will not be able to say that I did not warn you: imposing 
a text 5 allies to 1 delegate is not a warranty of success, all the more 
than we do not oppose the document and the work achieved.

We only oppose the exclusive, the exclusion and the lack of scalability, 
flexibility, capacity for innovation and evolution.
jfc

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

---

From: Martin Duerst <[email-masked]>
Date: Fri, 22 Jul 2005 10:44:49 +0900

[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).

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. 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.

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".

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.

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.

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.

 >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.

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.

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.

Except for purely superficial syntactical issues such as subtag length,...,
I haven't seen any evidence from you (or from others) that the current
draft lacks scalability, flexibility, extensibility, or capacity for
innovation.

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.

Regards,    Martin.

---

From: r&d afrac <[email-masked]>
Date: Fri, 22 Jul 2005 17:21:02 +0200

Dear Martin,
I will try to address this serious mail as seriously as possible. I am on 
vacations with many family things around.

>(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.

>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

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 
[email-masked] 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.

>strongly indicate that we have (rough) consensus to NOT have a

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.
>

This depends essentially on the "complements/replaces"

>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"?

> 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.).
>
>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.

>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 
[email-masked] 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 ...

>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 
[email-masked] (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.

>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.

>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?

>draft lacks scalability, flexibility, extensibility, or capacity for

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.

>increases scalability, flexibility, capacity for innovation and

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 27 Jul 2005 00:41:34 -0700

Hi -

Has anyone been persuaded by Jefsey's arguments that we need to
re-open the discussion of private-use (sub)tag syntax and compatibility?
Unless there is support for re-examining this decision, I believe it is
in the best interest of timely completion of our work to leave this issue closed.

Randy, ltru co-chair

----- Original Message ----- 
> From: "r&d afrac" <[email-masked]>
> To: "Martin Duerst" <[email-masked]>; "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Friday, July 22, 2005 8:21 AM
> Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of theUN disclaimer
>
> Dear Martin,

---

From: Erkki Kolehmainen <[email-masked]>
Date: Wed, 27 Jul 2005 12:01:13 +0300

I'd support the notion to leave this issue closed for this WG. We 
urgently need to provide the user community with a reasonably good, 
working solution now. Nothing prevents that solution from being improved 
at a later stage, provided that there will be an agreement on how. If at 
some point of time some other kind of an expanded solution would be 
convincingly demonstrated to provide real benefits over what can be 
achieved with the present one, the task to re-examine the decision could 
be assigned to some (other) group at that time.

(Incidentally, for Jefsey's information: My mother tongue is Finnish, 
and I come from a country with several recognized minority languages. 
The Research Institute for the Languages of Finland supports also 
Swedish, the three Sámi languages spoken in Finland - Northern Sámi 
(also spoken in Norway and Sweden), Inari Sámi and Skolt Sámi - and 
Romani as spoken in Finland plus the Finnish sign language(s). RILF also 
works with other languages, e.g. Carelian.)

Sincerely, Erkki I. Kolehmainen

Coordinator, Cultural Diversity Issues in ICT
Research Institute for the Languages of Finland (RILF)

---

From: Martin Duerst <[email-masked]>
Date: Sat, 30 Jul 2005 16:12:56 +0900

>in the best interest of timely completion of our work to leave this issue 
closed.

[chair hat off]
I very much agree with others that this issue can and should be left
closed. If anything, it has only become even clearer than before in the
most recent discussion than before that the WG's current rough consensus
on this issue is the best way to move forward, and that JFC hasn't
brought up a substantial issue.

Any of my other emails on this issue should be taken in light of the
comment above: To make things even clearer for those that may still
need additional clarification (including external people reading these
archives later).

Regards,   Martin.

---

From: r&d afrac <[email-masked]>
Date: Sat, 30 Jul 2005 17:07:45 +0200

>need additional clarification (including external people reading these

To these people,
please note that this is a private subjective (*) position of a co-Chair on 
a fundamental point he is to rule about, deciding if there is an existing 
rough consensus or not. In Justice this would obviously cancel his further 
decisions. All the more than he underlines that "_any_ [chair hat on and 
off] of my other emails on this issue should be taken in light of the 
[pivate - chair hat off] comment above". The bias becomes obvious when this 
response is precisely a response to ... the other co-Chair asking if this 
issue should be closed, what he will have to ... co-decide himself!

(*) the subjective nature of the position and its oddity is demonstrated by 
the fact that this mails follows by 12 minutes another mail where he carry 
with me, and on this specific matter, and with arguments the reader will 
appreciate the value but which are not final, one of the discussions "which 
brings no substantial value", and he says he wants to see closed ....

I will obviously not appeal for this example, among so many others, of the 
way this WG openly proceeds towards a consensus by exhaustion. I note that 
the preceding mail, documented a case of "exclusensus" against my positions.
jfc