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; Mon, 01 Aug 2005 11:49:11 +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 1B66A320138 for ; Mon, 1 Aug 2005 11:49:11 +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 09679-01 for ; Mon, 1 Aug 2005 11:49:06 +0200 (CEST) X-Greylist: delayed 00:05:04 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 071D332012D for ; Mon, 1 Aug 2005 11:48:54 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DytLW-00036e-Sp; Sat, 30 Jul 2005 11:33:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DytLU-00032m-Sc for ltru@megatron.ietf.org; Sat, 30 Jul 2005 11:33:52 -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 LAA16447 for ; Sat, 30 Jul 2005 11:33:50 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DytrO-0007IJ-7H for ltru@ietf.org; Sat, 30 Jul 2005 12:06:50 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DytLQ-00022g-UF for ltru@ietf.org; Sat, 30 Jul 2005 08:33:51 -0700 Message-Id: <6.2.1.2.2.20050730173205.0593beb0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 30 Jul 2005 17:33:20 +0200 To: "LTRU Working Group" From: r&d afrac Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags - Last Call proposed text 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: e16ce0269ccb2f59707d16700199d13b Cc: 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="===============0944876887==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org X-Virus-Scanned: by amavisd-new at alvestrand.no --===============0944876887== Content-Type: multipart/alternative; boundary="=====================_26946296==.ALT" --=====================_26946296==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed [sorry, I mistakenly answered Lee only. Apologies - Last Call text submitted in this mail] Dear Lee, I think I see your point. You say "x-" permits "private use" like in "private nets" (intranet). So there is a conflict only if a intranet A wants to talk to intranet B. This is an interesting point (for which I would be interested to get an example of use) I never considered. But I do not think that private use is understood this way by the Draft. It is not the way I want it, not the way it is understood by applications and users I relate with, nor by the ietf-languages@alverstrand mailing list. It is understood in a way which permits to support ISO 639-3 today or ISO 639-5, or ISO 639-6, under RFC 3066 or bis in using "X-639-3-alpha3" - please look at Draft 2.2.7 final paragraph. However, your proposition could be an interesting way out for the Draft to address the issue: - your example documents "x-" as the entrance into closed virtual namespaces. Since I never met the need, I cannot comment on the demand. I suppose this could be qualified, among others, as an experimental namespace. If you say that 8alpha is OK for them, I cannot object. Let it be! - the following paragraph should then be inserted after 2.2.7: "2.2.8 Escape Sequence For compatibility with other language tags systems the "0-" singleton escape sequence if provided. It means that the "0-" singleton MUST be considered as an end of a language tag as documented by this memo. Everything following the "0-" singleton escape sequence, even after another singleton, MUST be treated as foreign to the present rules and documented registry; and as defined by another set of rules and another registry. To avoid confusion that set of rules and registry SHOULD be identified by a scheme built in using a unique identifier belonging to its registry manager, or defined by an RFC." The "0-" escape sequence should be added to the ABNF. But I am not good enough to say how. This way, "0-ISO.639.6:xxxx" would be an acceptable Language ID. Where "ISO:" is the scheme and "ISO.639.3:" obeys to the rules of private schemes - using a ".". Martin can tell if it should be "ISO.639.6" or "ISO.6396". I suppose the first one is the proper one to respect the ISO document hierarchy. Does that address your remark? jfc At 20:32 29/07/2005, L.Gillam wrote: >Jefsey >The point of the analogy is this: >say we have two groups A and B > A have their x- private use extensions, B have their own x-. > >Since A and B do not wish to exchange information there is no problem. >Only when A and B want to exchange do might they need to redefine their >use of the x-. At this point, one suspects they might agree to use >x-justa-, x-justb-, x-aandb-. There are no implications for group C who >have their own scheme but don't desire an exchange with either A or B. > >The same would be true if we combined 2 separate class B networks - we >would be forced into some kind of address reassignment if there were conflicts. > >The only constraint being that they must restrict their hyphenated fields >to 8 though the number they can use is effectively unlimited depending on >the application (consider 192.x.x.x). Besides, the 8 characters are codes, >not names. > >Best Regards. > > >---------- >From: r&d afrac [mailto:rd@afrac.org] >Sent: Fri 29/07/2005 18:58 >To: Gillam L Dr (Computing) >Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags > >Dear Lee, >I am not sure I understand the question. If you mean tghat it is some >similar thinking for the space master, sort of. > >I only mean that there are many ways to make sure that a private space does >not conflict with another private space (ask Martin about URI). The point >is to designate the namespace of the private user. My point is simply that >with more than one billion of users each having right to one name space, >there is a ... lack of room. My point is only that the way the unicity is >organised is either to be defined by this WG or to be permitted by this WG >(there are miryad of possibilities and needs). > >And that in refusing the necessary space and characters, they condemn users >to oppose their scheme and therefore condemn their scheme. >The lack of comment of Doug, shows that he has no proper solution. He just >says that he waits for the EITF LC while he promised that he had a solution >avoiding that. If he had he would only pick the few examples I listed and >would document his response. > >All the best. >jfc > > > >On 18:42 29/07/2005, L.Gillam said: > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org > > > > [mailto:ltru-bounces@lists.ietf.org]On > > > Behalf Of r&d afrac > > > >[snip] > > > > > 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. > > > > > > >Jefsey, > > > >Are you considering, for example, the use of Private IP addresses - > >the Class B and Class C networks? > >e.g. > http://www.michna.com/kb/IpAddressesPrivate.htm > > > >In this scheme, as I understand it, only consenting "machines" > >will be referred to by a specific address - e.g. 192.168.0.54 > >and if you're on another network you should not assume that the > >same identifier refers to the same machine. > > > >Similarly, unless you have a private agreement on what follows > >the x-, you should not make any assumptions. Elsewhere, this > >might be described as the difference between "blind" (we know > >what we're getting and don't need to look at it) and "negotiated" > >(we need to make our own agreement about it) interchange. > > > >But, would you willfully ignore the numeric formatting required > >for an IPv4 Class B network? It is private use after all. --=====================_26946296==.ALT Content-Type: text/html; charset="us-ascii" [sorry, I mistakenly answered Lee only. Apologies - Last Call text submitted in this mail]

Dear Lee,
I think I see your point. You say "x-" permits "private use" like in "private nets" (intranet). So there is a conflict only if a intranet A wants to talk to intranet B. This is an interesting point (for which I would be interested to get an example of use) I never considered.

But I do not think that private use is understood this way by the Draft. It is not the way I want it, not the way it is understood by applications and users I relate with, nor by the ietf-languages@alverstrand mailing list. It is understood in a way which permits to support ISO 639-3 today or ISO 639-5, or ISO 639-6, under RFC 3066 or bis in using "X-639-3-alpha3" - please look at Draft 2.2.7 final paragraph.

However, your proposition could be an interesting way out for the Draft to address the issue:

- your example documents "x-" as the entrance into closed virtual namespaces. Since I never met the need, I cannot comment on the demand. I suppose this could be qualified, among others, as an experimental namespace. If you say that 8alpha is OK for them, I cannot object. Let it be!

- the following paragraph should then be inserted after 2.2.7:

"2.2.8 Escape Sequence

For compatibility with other language tags systems the "0-" singleton escape sequence if provided. It means that the "0-" singleton MUST be considered as an end of a language tag as documented by this memo. Everything following the "0-" singleton escape sequence, even after another singleton, MUST be treated as foreign to the present rules and documented registry; and as defined by another set of rules and another registry. To avoid confusion that set of rules and registry SHOULD be identified by a scheme built in using a unique identifier belonging to its registry manager, or defined by an RFC."

The "0-" escape sequence should be added to the ABNF. But I am not good enough to say how.

This way, "0-ISO.639.6:xxxx" would be an acceptable Language ID. Where "ISO:" is the scheme and "ISO.639.3:" obeys to the rules of private schemes - using a ".". Martin can tell if it should be "ISO.639.6" or "ISO.6396". I suppose the first one is the proper one to respect the ISO document hierarchy.

Does that address your remark?
jfc

At 20:32 29/07/2005, L.Gillam wrote:
Jefsey
The point of the analogy is this:
say we have two groups A and B
 A have their x- private use extensions, B have their own x-.
 
Since A and B do not wish to exchange information there is no problem. Only when A and B want to exchange do might they need to redefine their use of the x-. At this point, one suspects they might agree to use x-justa-, x-justb-, x-aandb-. There are no implications for group C who have their own scheme but don't desire an exchange with either A or B.
 
The same would be true if we combined 2 separate class B networks - we would be forced into some kind of address reassignment if there were conflicts.
 
The only constraint being that they must restrict their hyphenated fields to 8 though the number they can use is effectively unlimited depending on the application (consider 192.x.x.x). Besides, the 8 characters are codes, not names.
 
Best Regards.

From: r&d afrac [mailto:rd@afrac.org ]
Sent: Fri 29/07/2005 18:58
To: Gillam L Dr (Computing)
Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags

Dear Lee,
I am not sure I understand the question. If you mean tghat it is some
similar thinking for the space master, sort of.

I only mean that there are many ways to make sure that a private space does
not conflict with another private space (ask Martin about URI). The point
is to designate the namespace of the private user. My point is simply that
with more than one billion of users each having right to one name space,
there is a ... lack of room. My point is only that the way the unicity is
organised is either to be defined by this WG or to be permitted by this WG
(there are miryad of possibilities and needs).

And that in refusing the necessary space and characters, they condemn users
to oppose their scheme and therefore condemn their scheme.
The lack of comment of Doug, shows that he has no proper solution. He just
says that he waits for the EITF LC while he promised that he had a solution
avoiding that. If he had he would only pick the few examples I listed and
would document his response.

All the best.
jfc



On 18:42 29/07/2005, L.Gillam said:


> > -----Original Message-----
> > From: ltru-bounces@lists.ietf.org
> > [ mailto:ltru-bounces@lists.ietf.org]On
> > Behalf Of r&d afrac
>
>[snip]
>
> > 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.
> >
>
>Jefsey,
>
>Are you considering, for example, the use of Private IP addresses -
>the Class B and Class C networks?
>e.g. http://www.michna.com/kb/IpAddressesPrivate.htm
>
>In this scheme, as I understand it, only consenting "machines"
>will be referred to by a specific address - e.g. 192.168.0.54
>and if you're on another network you should not assume that the
>same identifier refers to the same machine.
>
>Similarly, unless you have a private agreement on what follows
>the x-, you should not make any assumptions. Elsewhere, this
>might be described as the difference between "blind" (we know
>what we're getting and don't need to look at it) and "negotiated"
>(we need to make our own agreement about it) interchange.
>
>But, would you willfully ignore the numeric formatting required
>for an IPv4 Class B network? It is private use after all.
--=====================_26946296==.ALT-- --===============0944876887== 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 --===============0944876887==--