"no, let's not go down that path" Sincerely, Erkki I. Kolehmainen Randy Presuhn wrote:
Hi - Rather than addressing the numerous points and assertions individually, I'd like to get a hum from the working group: Should we adopt the general course of action outlined below by Jefsey? I'm not looking for point-by-point responses at this time, just a succinct "yes, let's adopt the general approach Jefsey proposed," "no, let's not go down that path," or "I'd like to hear more discussion of his proposal before deciding." Randy, ltru co-chairFrom: "JFC (Jefsey) Morfin" <jefsey at jefsey.com> To: "Randy Presuhn" <randy_presuhn at mindspring.com>; "LTRU Working Group" <ltru at ietf.org> Sent: Tuesday, May 10, 2005 7:02 AM Subject: Re: [Ltru] RFC 2277 - considerationsDear 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 at lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru
_______________________________________________ Ltru mailing list Ltru at lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.