Message-Id: <6.2.1.2.2.20050709144837.0398f9f0@mail.afrac.org>
Date: Sat, 09 Jul 2005 15:54:33 +0200
To: "Doug Ewell" <dewell@adelphia.net>,
	"LTRU Working Group" <ltru@ietf.org>
From: r&d afrac <rd@afrac.org>
Subject: Re: [Ltru] Re: status? last call?
In-Reply-To: <007901c58450$44398e80$030aa8c0@DEWELL>
References: <20050708202214.FJXR27419.mta2.adelphia.net@megatron.ietf.org>
	<007901c58450$44398e80$030aa8c0@DEWELL>
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

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@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru