Message-Id: <6.2.1.2.2.20050510123012.04620b40@mail.jefsey.com>
Date: Tue, 10 May 2005 16:02:51 +0200
To: "Randy Presuhn" <randy_presuhn@mindspring.com>,
	"LTRU Working Group" <ltru@ietf.org>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [Ltru] RFC 2277 - considerations
In-Reply-To: <001001c55829$830b81c0$7f1afea9@oemcomputer>
References: <6.2.1.2.2.20050508032918.039af710@mail.jefsey.com>
	<6.0.0.20.2.20050508154021.06275280@itmail.it.aoyama.ac.jp>
	<01LO1QSCZ7S800004T@mauve.mrochek.com>
	<6.2.1.2.2.20050509181241.048ab7f0@mail.jefsey.com>
	<002a01c55815$27558240$7f1afea9@oemcomputer>
	<6.2.1.2.2.20050510022435.041290c0@mail.jefsey.com>
	<001001c55829$830b81c0$7f1afea9@oemcomputer>
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 Randy,
it is always a pleasure to repeat the same thing to you. So I will do it again.

At 04:05 14/05/2005, Randy Presuhn wrote:
>Given the depth and breadth of expertise of the participants, I'm willing 
>to take their lack of confusion as a sign that we know what we need to do.

Never thought a WG was a resume contest, but I suppose I have no problem 
with that.

Now, it would be surprising that people who came for a purpose (which will 
never be globally consensual, two negative Last Calls), would be confused 
on what they want to achieve. Those who disagreed but me gave up.

>Could you *please* identify the *specific* text in the draft you would 
>like to add / remove / replace?

I thought it was clear to you, since end of December.

Remove: the whole draft.

Add: the XML oriented parts of the Draft in the second document where they 
belong, together with a consistent documentation of its filters and working 
tools (you oddily have no problem to add them to langtag libraries but you 
cannot add them to charset libraries?), a good explanation of the charset 
violation needs, a clear assessment/commitment of the resources required 
from IANA

Replace: make BCP 47 an Internet technology (RFC 1591, 1958, 2277, 2301, 
3066, etc., etc.) consistent framework for the support of language context 
identification as one of the Multilingual Internet building blocks, 
together with others works such: within IETF (OPES, IDN, LDAP, PPP, SNMP, 
etc.), outside (for the time being) the IETF (those I know of: classes, 
groups, externets, CRC, ISO 639-X, UNITAG). And let document a consistent 
IANA external tables and values management consistent or aggregating the 
current registries.

>The IESG reviewed our charter before approving it.

IESG will also review the deliverables of this WG before accepting them for 
a Last Call and then after the Last Call. And during an appeal if they 
approved it. So would IAB after that if they confirmed.

What is the interest to have something which pleases a small score of 
supporters and is defeated by lack of global consensus? If the problem is a 
IANA registry conflict please tell us. If the problem is to ascertain the 
Unicode table vs. ISO 10646 please tell us. If the problem is to make ISO 
15924 the center of the world please tell us. If the problem are W3C 
analysis difficulties please tell us. If the problem is rooted in the CLDR 
structures please tell us.

Your problem is neither to produce a Draft, nor to shut my mouth. Your 
target is to address a problem. Either it is the one written in the Charter 
and IMHO its is partly erroneously worded the way you seem to read it. Or 
it is another one, and I doubt you can solve it if you do not spell it. If 
it is part of both, let sort it out first.

>You even commented on the proposed charter while the IESG was reviewing 
>it, so if anything was unclear, you certainly had opportunity to make your 
>view heard at that time.

I commented positively on your proposition to have a WG. This is what I 
asked for early January. I had proposed the creation of a WG-TAGs because 
this is what I am working on in a much broader scope. I was not opposed on 
a WG on language and I detailed my conditions a minima. These conditions 
are not spelled out in the Charter, but since the Charter has been 
submitted/reviewed to/by the IESG it is mostly consistent with the whole 
Internet architecture (all the more that it MUST be read in its perspective).

>This working group's job is to produce two documents, as spelled out in 
>the charter.  You are the only participant who seems to have any 
>difficulty understanding the charter.

May be I am the only one with a very low IQ? Did you forget one thing, I am 
also the only one who does not to speak English. That alone should be an 
alarm for you when addressing a multilingual issue. I am also the only one 
in various areas of importance to this topic (a ccTLD registry, the founder 
of the oldest user/operator structure, a former @large panelist, an active 
contributor to the WSIS process where multilingualism is a priority, etc.).

I only think there is a qui pro quo you should have resolved first. You 
proposed a text with a W3C/Unicode culture, it was read by the IESG with an 
Internet culture. I read it with another more global network culture. All 
this makes the Internet, but one has to accept to have a limited 
methodology. This starts with reviewing what all the participants have read 
and accept in your text, not  to end with it when everyone is gone.

You said there were thorny points in the charter. There are. I am not sure 
you saw them all. I just waited for the list to be calm enough to rise the 
charset issue.

Please understand, as I mentioned it in my response to the Chairs and ADs, 
I am as everyone else entitled to a Charter review by the WG to make sure I 
am not wrong, before producing my own Draft. Having a fragmented review of 
the Charter while most of the people disappointed with the Draft are gone, 
only delays the whole process and does not help. Neither me, nor the 
current Draft.

>No one else on this mailing list has expressed any confusion as to what 
>our deliverables are.

This is precisely the problem. On such a matter, there should have been 
much more. This only means they are not here.

Language tags, the way authors see them, are a deep change in the Internet 
architecture. This has lead to the opposition met during the first two last 
calls. This WG should have started in assessing that change. Its reasons, 
its implications. debreifing the opposition, not just jumping at an 11th 
and 12th version of the same proposition with the same text.

- They want a change which affects/opposes a consistent corpus RFC.
- I see one of the seeds of the response to an urgent market and political 
demand not addressed until now.

Both have to be discussed. Better here than on the general list during the 
third Last Call, all the more if it is opposed by a short Draft of mine.

You just start listing some of the points of my last month review (delay is 
not on my side) on the management system you chose. Thank you: this will 
save me the time of listing during the Last Calls all the points I rose 
which have not been discussed - what would have been poor (I am not sure 
however you will list them all?). Now they have to be addressed. But not 
all them are listed and most are listed in a way no one can understand what 
it refers to without accessing the whole review each time and to figure out 
where it is. I gave each point a "#" number (there are 55 of them). Why not 
just to paste them into your system before commenting them? Also, in the 
follow-up, why to assume people agree with you (and not me) because they 
did not comment?

Think that my draft would use the Charter framework and quotes the 
concerned RFCs, documenting how to support the XML, DNS, IDNA, OPES, LDAP, 
PPP, etc. etc. needs (even the non documented ones of CLDR) in the scalable 
way the Internet has always supported them with success up to 
now.  Discussing the reducing ways others may have proposed over time which 
have been opposed with that success. Scalable, simple, robust, stable, 
secure will be the keywords. I could also propose a F2F meeting before the 
Paris meeting. I would propose people from the MINC, UNESCO, WSIS, 
Francophonie, etc. to attend.

I accept there will be lacks in such a document of mine as I lack inputs 
from the WG debate on the charter, and I have not the time, the expertise 
and the interest to became a specialist of all the IETF oddities it should 
aggregate and consolidate, such as the RFC of Ira McDonnald, and all the 
times the internationalisation of the ASCII Internet is considered in RFCs. 
IMHO what you miss is that what you made at stake is the transition from 
internationalisation to multilingualisation (actually to vernacularisation) 
- user to user relations, over brain to brain, over end to end. I accept 
this is beyond what this WG is able to discuss, but this This is _your_ 
decision in wanting to replace BCP 47.

I frankly prefer focusing on the Multilingual Global Network (MGN) - as it 
should progressively result from our current work, the WSIS, the dialog 
between ITU, WSIS and the operators efforts (currently engaged). Let be 
candid: if this WG does not produce a Draft along that lines, the Draft (or 
eventually an RFC) and the IANA registry will only be a problem to forget. 
Is that what you really want?

Here is what I propose for a serious review of the topic:

1. what I had not time to do it yet: a dump of the whole IETF corpus and a 
grep on "international" and "lingual" to know which RFC can be affected and 
which experience has been gathered in there. There are more than you 
thought in preparing the Charter.

2. to seriously review the problems, starting with those quoted by the 
charter. What they really mean. What are the architectural implications 
they may have in an MGN framework. They are not perfect, but they will lead 
to most of them.

3. what architectural responses they may call for and what this implies on 
the structures of the contents' containers.

4. _IF_ there are architectural changes (I doubt there are much, as the MGN 
IMHO concerns higher layers than the end to end architecture) what are 
they? IMHO they concerns mainly the way to use IPv6, OPES and the DNS due 
to current implication of the DNS in the architecture of usage and hyperlinks.

5. what is the stable, simple, robust framework the IETF technology should 
provide to the applications designers.

6. to seriously review the way this can be made supported by IANA and CRCs. 
And let implement test applications.

7. let discuss how to address the evolutions/trasnsitions possibly implied 
at a network level.

This makes the first document.


Then a second document should use that stable foundations to write the 
specific solution called by the documentation of the charset in the W3C 
containers and the stabilisation of the XML langtag, its filtering, sorting 
etc. Another document could be proposed by Unicode (if free of IPRs) to 
document the CLDR approach, propositions and specific own usage (if any) of 
this framework.

I accept that the expertise of this WG is more oriented towards the second 
document and I am more interested in the first one. There are two possible 
responses to that:

1. either to follow my proposition above and make the general list aware of 
what we plan to discuss. I bet there will be new comers with depth and 
breadth of expertise in the concerned areas (even if IETF, IAB and IESG is 
not much aware/motivated in the lingual areas).

2. or to follow the recommendations received on the general list during the 
Last Call. Let us stop pretending changing BCP 47: let consolidate RFC 3066 
as it is today, with its relations to RFC 2277 and 2301, and publish a 
specific solution for XML. I do not think anyone will oppose this. Only 
some people will find it odd if you document IETF values violation they may 
want the IETF/W3C liaison committee to approve. This is the RFC 3066 
bis/ter option. The real work will be carried afterward. And your problem 
will be quickly fixed. This is what I proposed the day we started the WG 
and to work with the Authors on that. We could be done for a long. Actually 
the WG was even not necessary.

I fully understand this is does not make things simple for you. But you 
decided that the most complex issue Internet is to face since its 
inception, and delayed for 20 years, was something simple. It is not.
All the best.
jfc





















_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru