Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags - Last Call proposed text

From: "L.Gillam" <[email-masked]>
Date: Tue, 2 Aug 2005 10:49:04 +0100

Jefsey,
 
Let us assume that:
1. You want a private set of language identifiers
2. You document this scheme 
3. You want to remain in conformity with the current document
 
Then let's suppose
1. You use x-
2. You document that your first two fields identify your scheme because that's what you want to do [jefsey-20050802]
3. You document that your third identifier is a 4-letter field that you want to take from the future 639-6 standardised set [xxxx]
4. Your system looks like [x-jefsey-20050802-aaaa]
5. Your tags may consist entirely of private use subtags BUT they MUST conform to format and content constraints defined in the ABNF. These would seem to be fairly minimal conditions for conformity.
6. You share this document, privately, with those you want to exchange data with
 
Now, remember that there's more than one way to skin a cat ..... some may implement a matching algorithm by checking one field at a time
and throwing away the hyphen while others split on the hyphen and deal with the resulting fields expected each to be of max length 8 because
that's what the spec says. Anything that does not contain a valid character is incompatible. Anything that is 9 characters long? Try putting
9 characters into an 8 character database field or char[8] and see what happens - recall the Y2K problem.
 
Of course, if you don't care about such things, you are at liberty to do as you wish. At this point, you are outside the spec and can't expect existing systems to be compatible with yours. 
 
Now consider what a troll does. 
 
Please don't conflate the issue by discussing the meaning of "private", the Charter, or the use of (XML?) schemes.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of r&d afrac
Sent: 01 August 2005 16:18
To: Gillam L Dr (Computing)
Cc: [email-masked]
Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags - Last Call proposed text

Dear Lee,
1. I have dificulty understanding your comment. You defend a point I agree? and you do not addres the Last Call text I presented?
2. RFC 3066 mixes political, Internet standard process and standard track issues. This WG is chartered to clarify this confusion.
3. instead, the current Draft increases this confusion in adding constraints. This favors commercial dominant interests.

On 12:53 01/08/2005, L.Gillam said:

Section 2.2.7 is (was) clear:
    Private use subtags are used to indicate distinctions in language
   important in a given context by private agreement.  

I could only understand we would disagree if you wanted to regulated what is the meaning of "private"?

Now, nobody can prevent you from creating implementations that are going to

be incompatible with others that conform to 3066 past, present, or future. 

I do not know what you are talking about. There is only one RFC 3066. I am only interested in addressing the charter in correcting RFC 3066 inadequacies.

Similarly, nobody can stop you from using two letters to represent whatever
you want them to, or saying "yes" for "no". On the other hand, if you distribute
code that is not compatible with that of others whose code conforms to 3066,

? what are you talking about? Or is it a troll?
The only intent here is by the author to authors to abuse from the BCP quality of RFC 3066 to forbide more possibilities than their limitations. 

isn't it at this point that *you* would be breaking the Internet?

If the Draft is "the Internet" then we do not speak of the same thing. This actually boils down to this: it seems that the Internet the authors  presuppose is not the one many want. Question is to know if the IETF, IESG, IAB, GAC, IANA, the WSIS Forum will endorse that.

Besides, why would you want to break compatibility with other implementations (breaking the Internet?) with: 
0-ISO.639.6:xxxx

I do not see how 0- breaks compatibility with non existing implementations.

when
x-ISO-639-6-xxxx
would appear to be both conformant and sufficient?

This violates the format of schemes. But, mostly this would be totally confuse. I gave examples to Doug: he gave up. You are most welcome to document how this format could support them and avoid "breaking the Internet". I am certainly deeply interested, but I do not see how this format could support the many, many language related issues overlooked by the Draft.
jfc

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: r&d afrac <[email-masked]>
Date: Tue, 02 Aug 2005 15:41:28 +0200

Dear Lee,

>3. You want to remain in conformity with the current document

I do not want to stay in conformity with the intent of the authors of the 
current document. I want the IETF to produce a document in conformity with 
users needs. Anyway we want to find the best, simplest, most stable 
solution. Let see if your proposition could do it.

>1. You use x-

You are here outside of the debate since I responded you that your point 
was well done, that I abandoned the claim on "x-". I introduced a text to 
support the "0-" escape sequence. You are just pushing for the third time a 
point you won.

>2. You document that your first two fields identify your scheme because 
>that's what you want to do [jefsey-20050802]

We agreed of the feasibility of that in the private use context you 
documented. We agreed that however that "jefsey" is not an URI and that 
there would be problem outside of the private context you considered and I 
accepted.

However your point calls for a comment: there is no scalability. "jefsey" 
happens to be a unique name in history (except a US slave of the XIX 
century). Everyone cannot use a unique name of less than 8 alphanum. URI 
are defined by RFCs. They use dots and even @ signs.

>3. You document that your third identifier is a 4-letter field that you 
>want to take from the future 639-6 standardised set [xxxx]
>5. Your tags may consist entirely of private use subtags BUT they MUST 
>conform to format and content constraints defined in the ABNF. These would 
>seem to be fairly minimal conditions for conformity.

No. The minimum in an IETF Best Practice is that they refer to user needs 
and practices. We all know two things:
- Microsoft Word uses 5 descriptors for a text (language, script, country, 
dictionary, style)
- the way RFC 3066 is nicknamed.

>6. You share this document, privately, with those you want to exchange 
>data with.

The two most important keys to an IETF document IMHO are pertinence and 
scalability. RFC 3066 and this Draft are for typographers not for network 
protocols. Do you impose limits to the scalability of my privacy? I know 
that you do not want to discuss "privacy" :-)

>Now, remember that there's more than one way to skin a cat ..... some may 
>implement a matching algorithm by checking one field at a time
>and throwing away the hyphen while others split on the hyphen and deal 
>with the resulting fields expected each to be of max length 8 because
>that's what the spec says. Anything that does not contain a valid 
>character is incompatible. Anything that is 9 characters long? Try putting

Can you document why this would be of any inconvenience to me?

This is precisely because it would fail that I do not care. An author using 
a "private" tag, is by nature only interested in those able to read it. 
Others can even be considered as intruders to him. Even in the case you use 
"x-" and you just pick the 8 _first_ letters, what is the problem? The 
authors have said that there could be a problem and to be careful.

Let consider I filter spam on "0-jefsey.com:nav-fr" in a Navy related 
mailing list. If I copy you my mail, and you accept "en fr". it will fail. 
Great:we were not in tune, you would probably have not understood half of 
the words. Example: "prend le bout, embarque et tourne-le. Un coup de 
sifflet bref. La berloque.".

>  Of course, if you don't care about such things, you are at liberty to do 
> as you wish.

No. Because for historical reasons and Internet standard process oddity, 
RFC 3066 has been granted the status of BCP 47.

>At this point, you are outside the spec and can't expect existing systems 
>to be compatible with yours.

Again,
1. no one I know need other schemes to be compatible with RFC 3066 libraries.
2. the Draft results in making sure that every internet language related 
system is not compatible with other schemes.

>Now consider what a troll does.

I do not think trolling is the best way to obtain response between serious 
people.

>  Please don't conflate the issue by discussing the meaning of "private", 
> the Charter, or the use of (XML?) schemes.

"private" is necessary. As are necessary languages, script, regions. I 
would think you know better what a scheme than asking "xml?". The debate is 
not in this. The debate is in technical exclusion for commercial or 
political reasons, or not. I respect the commercial reasons but I do not 
think IETF must be ruled by commercial motivations (RFC 3869 and open 
competition). I can understand the political reasons, but then all the 
concerned parties must be consulted. In some other places this is named 
democracy. In IETF this is named efficiency.

All the best.
jfc

,

>1. I have dificulty understanding your comment. You defend a point I 
>agree? and you do not addres the Last Call text I presented?
>2. RFC 3066 mixes political, Internet standard process and standard track 
>issues. This WG is chartered to clarify this confusion.
>3. instead, the current Draft increases this confusion in adding 
>constraints. This favors commercial dominant interests.
>
>I do not know what you are talking about. There is only one RFC 3066. I am 
>only interested in addressing the charter in correcting RFC 3066 inadequacies.
>
>The only intent here is by the author to authors to abuse from the BCP 
>quality of RFC 3066 to forbide more possibilities than their limitations.
>
>If the Draft is "the Internet" then we do not speak of the same thing. 
>This actually boils down to this: it seems that the Internet the 
>authors  presuppose is not the one many want. Question is to know if the 
>IETF, IESG, IAB, GAC, IANA, the WSIS Forum will endorse that.
>
>>Besides, why would you want to break compatibility with other 
>>implementations (breaking the Internet?) with:
>>0-ISO.639.6:xxxx
>
>This violates the format of schemes. But, mostly this would be totally 
>confuse. I gave examples to Doug: he gave up. You are most welcome to 
>document how this format could support them and avoid "breaking the 
>Internet". I am certainly deeply interested, but I do not see how this 
>format could support the many, many language related issues overlooked by 
>the Draft.
>jfc