Message-Id: <6.2.1.2.2.20050730142943.039bc8b0@mail.afrac.org>
Date: Sat, 30 Jul 2005 16:06:09 +0200
To: Misha Wolf <Misha.Wolf@reuters.com>,
	LTRU Working Group <ltru@ietf.org>
From: r&d afrac <rd@afrac.org>
Subject: RE: [Ltru] [psg.com #1072] compatibility and private use tags
In-Reply-To: <1987416CA83AC7499AC772F92E2DBF780439A125@LONSMSXM02.emea.i
	me.reuters.com>
References: <1987416CA83AC7499AC772F92E2DBF780439A125@LONSMSXM02.emea.ime.reuters.com>
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

At 12:34 30/07/2005, Misha Wolf wrote:
>I'm completely neutral on JFC's desire for URI-like constructs for
>identifying languages.  It reminds me of the various schemes,
>proposed or implemented, for identifying glyph variants.
>
>What I do object to, is JFC's insistence that RFC 3066bis support
>his proposed scheme.  What JFC should do is write an RFC documenting
>his scheme.  If this gains sufficient support, then he and/or others
>can seek to persuade the relevant groups to incorporate support for
>his scheme in their larger endeavours.
>
>For example, if JFC does this, and if he gains support, it is not
>impossible that support for such a scheme could be included in RFC
>3066ter.
>
>Misha

Dear Misha,
Thank you for this. Unfortunately this is exactly what I want. And what 
authors keep refusing.
I am sorry, I probably did not explain it clearly enough. I will try to 
explain it better.

RFC 3066 is also BCP 47.

A BCP is the only Internet standard process reference which can be updated 
(because it describes a _current_ practice which may change). A BCP 
establishes a de facto standard in saying: "hey! here is what some do, this 
is the best you can also do" (hence the "Best" - NB you can also describe 
other practices, but you will present them as "Informational"). The RFC 
wearing the BCP "tag" is the current replacement of the RFC which received 
it. In the case of RFC 3066, if the Draft says "this document replaces RFC 
3066", it becomes a de facto Internet Standard procedure description as BCP 47.

1. this is questionable because it represents a proposed practice. This is 
only possible because Internet standard process documentation (the 
registry) are documented by BCP.

2. the current text _prevents_ any other scheme to be documented as you 
propose it. Even if someone intriduced an Informational memo IESG would not 
accept it, as a violation of BCP 47). The current Draft puts the 
Multilingual Internet (which will never use its scheme) outside of the IETF.

There are only three solutions, which have been abundantly explained by 
IETF gurus during the Last Calls. They will again be used to block this 
Draft in the next IESG Last Call:

1) either the Draft does not claim to be a replacement to RFC 3066, what 
will permits to write a framework document replacing RFC 3066. That 
framework (part of the Internet standard process) will support the Draft 
and other RFCs. Obviously the BCP Registry part should go, and the 
filtering aspects included.
2) either another Draft opposes this Draft.
3) or other item schemes concepts are given a way to freely develop through 
any Internet Global Community documentation process, including RFCs or ISO.

(1) I consider the first one as advisable. But a lengthy process.

(2) I planed the second one. But this was possible only if we had at least 
worked a little bit into the charter, to mutually educate on the real 
technical networking aspects to address. As documented, IETF is not 
informed nor motivated enough about the multilingual priority. Without this 
WG having worked on the involved key architectural issues there was no 
chance. This is why I engaged it through the usage/working code and 
commercial product approach: the IESG will have difficulties to ignore it, 
either during the Last Call if we can match the delay, certainly in appeal.

(3) I consider the third as an acceptable patch, and I submitted a text to 
that end which introduces an escape sequence and permits every other 
standard, document, RFCs, etc. to be produced without hurting the proposed 
solution, and complying with the Internet standard practices. It 
technically and administratively permits what you propose and we most agree 
about.


The Internet Global Community Members (developers, users, ccTLDs, Govs) I 
relate with through various organisations cannot accept the Draft as 
worded. Their general attitude (as I documented it) is simple: "no 
interest, they do not know what they touch, the project must be removed". 
And there are people, resources, etc. and vital needs involved enough to 
make sure of it.

I disagree with them, but - as you noted it - I am alone doing it. I do not 
want to die any more than others, but I think there are no winner in a 
global network dispute, only losers. I think we still can compose, in 
everyone's best interest, the way you say. But don't read me wrong: if we 
are to block the Draft, I will participate blocking it and it will be 
blocked. But I will continue to try to make it corrected, accepted and 
supported ASAP, because some think they need it. At least as long as I 
think it makes sense.

So far, the authors want to keep their exclusive/exclusion text. If you can 
help making them understand it is in no ones' interest ... you welcome.
Cheers.
jfc


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru