[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltru] Re: status? last call?



I am sorry I have to go to the Luxembourg meeting where I will not have email access, my battery just having failed me. I just see from that collection of mails that the IETF process has advantages but also meets its problems. This is certainly not easy to address. This may be why it is better at maintaining/reducing than at developping (cf. Harald Alvestrand, RFC 3774, etc.)

The two quotes below I think denote that kind of difficulty.

At 08:34 09/07/2005, Doug Ewell wrote:
Several fine examples of misrepresenting the words and intents of
others.  Addison wrote on 2005-01-04 on ietf-languages:

> Asking the IESG to abandon the Last Call because you don't like the
> draft or because you don't care for our responses to you is, frankly,
> odious. Let the process play out.

The Last Call process is precisely to permit to ask IESG to abandon a document in documenting why.

> Try to understand the African culture
> if you do not understand the coexistance of language, family, economy,
> poetry, in a quasi geographical continuity. What are going to mean
> there "sn, co, iv, bn, etc.???".

A person who knows not a single word of Shona and knows nothing of the
culture of the Shona-speaking people can still work to develop a tagging
mechanism by which Shona text can be indicated by use of the string
"sn".

This, I believe, describes perfectly why the Draft doctrine adds to the basic error of RFC 3066 attenuated by its lose application (that IETF has the capacity to correlate non protocol parameters). Jon Postel had clearly established it: this is none of the IANA business. Not only it seems that cultural empowerment is ignored by the author of this text. But, since the topic here is ISO 3166, it shows a remakable confusion between Senegal and Zimbabwe which precisely document my point and the difficulty to establish general rules in a world made of particulars.

Please, let save time. Let not wait for another negative last call and start from a clean sheet analysis of the Charter at the light of the world and Internet reality. Call this a non-starter, I call this a new-starter. Let understand where and why RFC 3066 may be wrong. How to correct it - probably in a totally different way from the current Draft. Let build the Global Lingual Codification Framework the Internet community needs. Then use the Draft relevant parts to support the XML, HTML, CLDR needs for those wanting to stay compatible with the old RFC 3066 approach.

jfc

PS. I do not see much success with call for a consensus. Too bad.








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