Re: [Ltru] RFC 2277 - considerations

[Erkki Kolehmainen <[e-mail]>]

"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-chair
> 
> 
>>From: "JFC (Jefsey) Morfin" <[e-mail]>
>>To: "Randy Presuhn" <[e-mail]>; "LTRU Working Group" <[e-mail]>
>>Sent: Tuesday, May 10, 2005 7:02 AM
>>Subject: Re: [Ltru] RFC 2277 - considerations
>>
>>
> 
>>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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ltru
> 



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