Message-Id: <6.2.1.2.2.20050729145302.0586ead0@mail.afrac.org>
Date: Fri, 29 Jul 2005 16:36:02 +0200
To: Erkki Kolehmainen <erkki.kolehmainen@kotus.fi>
From: r&d afrac <rd@afrac.org>
Subject: Re: [Ltru] Re: [psg.com #1072] compatibility and private use 
  tags
In-Reply-To: <42EA20E4.40506@kotus.fi>
References: <002601c59388$13799e60$030aa8c0@DEWELL>
	<6.2.1.2.2.20050728182357.049085d0@mail.afrac.org>
	<42EA20E4.40506@kotus.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Doug Ewell <dewell@adelphia.net>,
	LTRU Working Group <ltru@ietf.org>
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Dear Erkki,
as I noted it:

At 14:28 29/07/2005, Erkki Kolehmainen wrote:
>Dear Jefsey,
>re your note of 28.7.2005 to Doug Ewell, the following quotation is to me 
>an undisputable hard fact:
>  No private-use scheme can ever assure that it will not conflict with 
> another private-use scheme.  That is why they are private! [DE]

This pure non-sense!

The fact that they are private and they permit conflict are orthogonal. I 
will take a simple example: Domain Names are private yet they cannot 
conflict. Because we organised the name space for that. As I indicated (and 
documented) there are many ways to specify the organisation of the "x-" 
name space so it is both private and conflict free.

I am only sorry that you comment Doug remarks and my remark on its 
proposition, rather than the answer I made Doug requested. I understand 
why, but so will IETF/IESG/IAB/GAC/WTO/IANA. I would be interested in your 
comment on the problem rather than a repetition of your ideas.

>... and the following highly commendable:
>  The scheme proposed in the current draft does prevent conflicts with 
> existing parsers that conform to RFC 3066. [DE]

The "highly commendable" is an odd hyperbole. It is correct, or it is not.

It is correct only if private use is removed from RFC 3066. The current 
draft does NOT prevent conflicts with existing parser that conform to RFC 
3066 in the private area. This is precisely this claim which is wrong, 
which is objected by  the previous claim above (you cannot say both: there 
will always be conflicts and at the same time you prevent conflicts). This 
reality is not an enhancement called by the Charter.

>... and the following highly questionable:
>My approach does not want to respect your 8alphanum constraint, because 
>that constraint may come from previous RFCs you want to respect and I do 
>not give a damn about (never used them). [JM]

May I ask why is that "highly questionable"? I tend to think that liberty 
is an highly questionable issue.

But in standards, you can say (what I detail and you totally ignore): "you 
MUST not (religious) say that!", or you can say "ok, what shall we then do?".

>To all: In case it is not clear from my participation in this group, I 
>have read the draft and support it.

Noted. Always good to note than someone has understood the way IETF Last 
Calls work: in bringing positive support to questioned points. The problem 
now is with the co-Chairs. Do they consider and can document to the IETF, 
IESG, IAB (and will they help the lawyers in GAC, IANA, WTO):

- the WG actually covered the Charter without having proceeded to an 
evaluation of what the Charter calls for.
- they have obtained a document professional enough for a positive IETF 
last call, with all the specialised points they did not cover, all the 
missing definitions of what they discuss and without having reduced 
opposition to consensus it proposes.
- they have a consensus while the few objections I rose and documented (at 
their request) and did made seriously addressed yet, the mild support the 
Draft obtained from a small score of participants on a list of 60 WG-Members.

We are here in a search of a consensus. So, we are not really interested in 
what you support or not: we are interested in what to do for both of us to 
agree. I said the two simple things for that:

1. not to claim to replace RFC 3066. I do not make it a critical point for 
the user community however. RFC 3066 is an error. Replacing an error by 
another error is no big damage. It is however critical for the IETF to 
decide if it will document the Multilingual Internet or not, as no serious 
non-US industry aficionado will use that system. We are making IDNA again. 
Your decision, at the end of the day I am not concerned. I think Harald 
documented enough, and Brian Carpenter's responses and attitude seem to 
confirm, and this WG-ltru main topic of interest documented it: IETF is 
simply not able to understand the problem and should not get into it.

I think that if this is the attitude, some wording should be reviewed by 
the authors, to protect their future pride.

2. no to use a joke to exclude the real world. This joke uses  two 
elements: "x-" and "8alpha". They are orthogonal. There can be three 
responses to that:

- either to make "x-" free from limitations. You oppose: it is not 
compatible to RFC 3066. I say I do not care (I am the user) but you want to 
force me to do what you want. For my good sake, so I stay compatible with 
the past I never had.

- either to create "0-" as a new zero constraint area. This has no problem 
of retrofit. The only opposition could be that the authors lose their grip 
on language tags and industry. But they claim they are not commercially and 
politically biased. So there is definitely no problem.

- either to keep the existing text to make sure it will probably never be 
used. The inconvenience for some will certainly be real, and the load 
imposed on us to oppose will be heavy. But the protection granted to many 
many more is worth it. All the more than Liberty does not mean for us to 
win anytime soon, or even to win. Just to delay the mistake until the 
better solutions we work on have taken off and the existing other solutions 
which are not aware of the threat have been informed (I note that since 
this Draft claims to be compatible with RFC 3066, nothing impeach the W3C 
to make it a W3C document tomorrow, or the IESG to make it a complement to 
RFC 3066 as we propose it).

I would not want to be in Randy and Martin shoes today. "0- or not 0-"
jfc








_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru