Message-Id: <6.2.1.2.2.20050730175021.05a0d210@mail.afrac.org>
Date: Sat, 30 Jul 2005 19:34:54 +0200
To: Misha Wolf <Misha.Wolf@reuters.com>
From: r&d afrac <rd@afrac.org>
Subject: RE: [Ltru] [psg.com #1072] compatibility and private use tags
In-Reply-To: <T7274bdadf80a01f019af3c@lonsmime01.rit.reuters.com>
References: <T7274bdadf80a01f019af3c@lonsmime01.rit.reuters.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: LTRU Working Group <ltru@ietf.org>
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Dear Misha,
I am afraid I was not clear enough or may be you are not familiar with the 
details of the Internet standard process. Let me clarify.

On 17:19 30/07/2005, Misha Wolf said:
>Hi JFC,
>As you write yourself, the "C" in "BCP" stands for "Current".

Yes. As I explain the reason why RFC 3066 qualifies as a BCP if because, 
however current or not, the Internet standard process related issues are 
documented via BCPs. This is an unfortunate thing most periodically 
regret/object. It only permits to limit the number of series and of 
document types. So RFC 3066 is a BCP 47 because it documents a Registry. By 
no means because of the langtags.

But as a BCP it enjoys the privildeges and the constraints of BCPs.

>By no stretch of the imagination can your proposal (whatever its merits or 
>demerits) be described as current practice, hence it is not a candidate 
>for a BCP.

May be do you confuse between a "current practice" and a "best current 
practice". My current practice (using the langtag the users select it, ie 
having the community as a RA as ISO and as are non-profit ccTLDs) is a 
certainly a current practice which currently support millions of users via 
the DNS. The generalisation, with the project we work on, will also be 
certainly be a current practice possibly at the time of the IESG Last Call, 
and certainly at IESG and possible IAB and possible IANA etc. appeal time.

A BCP can document a practice in saying it is better. It cannot forbid an 
existing or a planned practice which does not hurt the network. Your role 
is to explain how using a "0-xxxxxx:xxxxxx:xxx-xxx.xxx, etc" semantic is 
hurting the network in a way you cannot patch.

>  I suggest that you follow the path I proposed in my earlier mail.  Then, 
> when work starts on RFC 3066ter, you can argue that your scheme
>should be incorporated.

I am sorry if I was not clear enough then. I am not interested in IETF 
"bis", "ter" etc. fancies as such. I am interested in the user-centric 
architecture MGN deployment. IETF only interests me if it publishes 
something of interest I can use, to make sure we do not conflict, and that 
it does not harm our work.

So your proposition is not possible. I am not interested in RFC 3066 xxx I 
consider as an error. I am only interested to know if it is only an error 
authors wants to adapt to fit the communities' demand, or if it is the 
political and commercial coup of industry leaders against 
open-source/public interest/general industry most tells me. In any case it 
will _not_ be permitted that anything - here or elsewhere - which would 
result into a political and a commercial unfair practice would develop 
under the IETF umbrella. I am sure you will agree with me on this.

No one wants a BUP 47?

>To anticipate any argument that the current drafts also do not represent 
>current practice, I say in advance that these drafts clarify what is 
>widely deployed today.

This is not something which falls under BCP. This Draft focuses on 
constraining/extanding technical issues which are outside of the Internet 
standard process. As such it does not qualifies as a BCP. It is regular 
standard track. It opposes best current practices is two ways:

- in trying to exclude competitive solutions - this is not the _IETF_ best 
current practice.
- in not considering the way others use the langtags what affects the 
Internet standard process and is relevant to its BCP part. Our opposition 
is on the (carefully?) non discussed registry management - and on the 
incredible ISO 11173 denial.

When you say "I found a good way to include scripts in the langtags" this 
is a pure standard track issue improving an existing technical solution.

When I say "I use my langtag registry to name lingual externets and to 
conform to ISO 11173 to permit the Multilingual Internet standard process 
to stay consistent with the other convergent technologies", this is a 
matter relating to the Internet standard process. In technically impeaching 
my registry to work properly (ex. ISO 11173) the WG abuses the additional 
BCP nature of the RFC 3066, and interfere with the Internet standard process.

This issue is complex. It is an absurd point of detail. I know, but it is 
blocking. We dispute on it for 8 months. I am very patient and we will not 
die and let the development of the Internet be delayed for years and given 
to a few corporations just to please your love of old RFC 3066 semantic.

>You have argued that existing deployment should not act as a barrier to 
>adoption of your scheme.  That argument is not compatible  with the letter 
>"C" in BCP.

I do not understand? You seem confusing who is who here. This Draft opposes 
what is a current practice. That language tags are decided by their users 
communities. You want to impose a IANA centralised directory. We have 
distributed reference centers.

The way you manage your langtags is your problem, the way we manage them is 
our problem. If you want to interfere with us to block our development we 
fight you. This seems simple enough?

The point is simply to know if your intent is to participate into a 
commercial/political trick or not. If not (as I suppose) we proposed a 
solution. You are most welcome to propose another one if you  think of a 
better one. Doug proposed one, but unfortunately it seems he gives up.

>You could propose that RFC 3066bis should state (in order to
>give implementors time to prepare for such changes) that it
>is anticipated that RFC 3066ter will relax some of the
>existing constraints (eg the 8-char limit).  W3C specs often
>do this: ie in version N+1 they give notice that it is
>anticipated that particular version N features will be dropped
>in version N+2.

This is a good idea in the proper direction. But I do not see why 
developers would need more than what I propose. And why we would give up 
our legitimate right (and the right of the users to see competition 
fostering quality).

My proposition seems extremely clear and fair.

1. as Lee suggested it, there could be a reason why X-8alpanum could be of 
use. Let keep it. I drop my claim on x-tags. As you may recall I objected 
the "x-" as adult oriented. So, no problem.

2. the "0-" escape sequence is an extremely simple sequence to implement. 
As it means "if you do not understand what follows: disregard it" I think 
it is completely acceptable to existing libraries.

There is a confusion between langtags used with the xlang: scheme and 
global langtags. I have no problem in having a text saying
"0- langtags SHOULD NOT be used with xlang:". Actually I do not thing that 
0-tags will be used in XML environment the way you think. However  XML/HTML 
may have to work in 0-tags environment and to adapt to multilingual 
architext versioning.

Most of all, I would like to forget this RFC 3066 saga which made us waste 
so much time. RFC 3066 is an error. As such it does not bother us much as 
we do not use it (at least the way the Draft wants to impose it). But we 
will not permit the IDNA political/commercial coup against us to repeat. We 
have learned. It took a lot of wasted time to get Vint Cerf acknowledge the 
IETF failure under the pressure of UN. But now we learned how to make it.

The decision is in the hands of the Authors.
Everyone will see their motivations.
But there will be no "IDNA bis."

jfc


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru