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

From: r&d afrac <[email-masked]>
Date: Sat, 30 Jul 2005 17:33:20 +0200

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