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

From: "L.Gillam" <[email-masked]>
Date: Mon, 1 Aug 2005 11:53:03 +0100

Jefsey,
 
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.  
 
item 5:
    No source is defined for private use subtags.  Use of private use
   subtags is by private agreement only.

item 6:
    Private use subtags are NOT RECOMMENDED where alternatives exist
    or for general interchange.  See Section 4.5 for more information
    on private use subtag choice.

and section 4.5:
   Private use subtags, like all other subtags, MUST conform to the
   format and content constraints in the ABNF.  Private use subtags have
   no meaning outside the private agreement between the parties that
   intend to use or exchange language tags that employ them.  The same
   subtags could be used with a different meaning under a separate
   private agreement.  They SHOULD NOT be used where alternatives exist
   and SHOULD NOT be used in content or protocols intended for general
   use.

Now, nobody can prevent you from creating implementations that are going to
be incompatible with others that conform to 3066 past, present, or future. 
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,
isn't it at this point that *you* would be breaking the Internet?
 
Besides, why would you want to break compatibility with other implementations
(breaking the Internet?) with: 
0-ISO.639.6:xxxx
when
x-ISO-639-6-xxxx
would appear to be both conformant and sufficient?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of r&d afrac
Sent: 30 July 2005 16:33
To: LTRU Working Group
Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags - Last Call proposed text

[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:[email-masked] ]
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: [email-masked]
> > [  <mailto:[email-masked]> mailto:[email-masked]]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.

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

---

From: r&d afrac <[email-masked]>
Date: Mon, 01 Aug 2005 17:17:50 +0200

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.

>    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"?

>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.

>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.

>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