Return-Path: Received: from murder ([unix socket]) by eikenes.alvestrand.no (Cyrus v2.2.8-Mandrake-RPM-2.2.8-4.2.101mdk) with LMTPA; Tue, 02 Aug 2005 17:52:36 +0200 X-Sieve: CMU Sieve 2.2 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 993A9320092 for ; Tue, 2 Aug 2005 17:52:36 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06313-03 for ; Tue, 2 Aug 2005 17:52:27 +0200 (CEST) X-Greylist: domain auto-whitelisted by SQLgrey-1.4.8 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 607E7320134 for ; Tue, 2 Aug 2005 15:43:52 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzx1c-0008MD-QJ; Tue, 02 Aug 2005 09:41:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzx1a-0008Lf-Uu for ltru@megatron.ietf.org; Tue, 02 Aug 2005 09:41:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19327 for ; Tue, 2 Aug 2005 09:41:40 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzxY2-0008W8-PH for ltru@ietf.org; Tue, 02 Aug 2005 10:15:17 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dzx1W-0000uq-8f; Tue, 02 Aug 2005 06:41:38 -0700 Message-Id: <6.2.1.2.2.20050802140412.03cd3ca0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 02 Aug 2005 15:41:28 +0200 To: "L.Gillam" From: r&d afrac Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags - Last Call proposed text In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A212BC9069@EVS-EC1-NODE1.surre y.ac.uk> References: <4A7C6FA2AB31194E80E13FE585F6A212BC9069@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c Cc: ltru X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1346540799==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org X-Virus-Scanned: by amavisd-new at alvestrand.no --===============1346540799== Content-Type: multipart/alternative; boundary="=====================_25151295==.ALT" --=====================_25151295==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:49 02/08/2005, L.Gillam wrote: > Jefsey, > Let us assume that: Dear Lee, >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 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. >Then let's suppose >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] >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. 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 >9 characters into an 8 character database field or char[8] and see what >happens - recall the Y2K problem. 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 , > >-----Original Message----- >From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On >Behalf Of r&d afrac >Sent: 01 August 2005 16:18 >To: Gillam L Dr (Computing) >Cc: ltru@ietf.org >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 --=====================_25151295==.ALT Content-Type: text/html; charset="us-ascii" At 11:49 02/08/2005, L.Gillam wrote:
 Jefsey,
 Let us assume that:

Dear Lee,

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

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.

Then let's suppose
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]
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.

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
9 characters into an 8 character database field or char[8] and see what happens - recall the Y2K problem.

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












,

 
-----Original Message-----
From: ltru-bounces@lists.ietf.org [ mailto:ltru-bounces@lists.ietf.org]On Behalf Of r&d afrac
Sent: 01 August 2005 16:18
To: Gillam L Dr (Computing)
Cc: ltru@ietf.org
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
--=====================_25151295==.ALT-- --===============1346540799== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1346540799==--