Subject: [Ltru] Re: [psg.com #1072] compatibility and private use tags

From: "Doug Ewell" <[email-masked]>
Date: Thu, 28 Jul 2005 08:21:48 -0700

I'm going to go out on a limb and respond to this, because the questions
actually sound like genuine requests for information.  None of my
responses below have any "secret" or "hidden" meaning, and must not be
taken as such.  Any attempt to twist my responses in a way I do not
intend, or otherwise misrepresent them,  or me, will cause me to go back
to ignoring subsequent posts by this individual.

r&d afrac <rd at afrac dot org> wrote:

> If your belief is genuine,

It is.

> and not pure comptempt of your competition as it resents it,

"Competition" is not the word I would have chosen.  "Opposition" is more
like it.

> can you document:
>
> 1. you warranty these scheme will prevent conflicts

No private-use scheme can ever assure that it will not conflict with
another private-use scheme.  That is why they are private!  The scheme
proposed in the current draft does prevent conflicts with existing
parsers that conform to RFC 3066.

> 2. will support a simple format such as x-schemes:name.subname:
> address:date-etc.

Yes.  You simply have to replace colons, full stops, etc. with hyphens,
and make sure each piece consists of 8 or fewer characters in the range
[0-9A-Za-z]:

x-schemes-name-subname-address-date-etc

> 3. will address the right of billions of users to document the way
> they want 20.000 languages in thousands of regions, the languages and
> scripting variations they may chose (private use is for that).

There is no freely available coding standard for 20,000 languages, but
you can put anything you like in a private-use subtag, including
regional detail down to latitude and longitude.  "fr-FR-x-VER" might be
French as spoken in Versailles.  "fr-x-484816N-0020708E" might be French
as spoken in a particular location in Versailles.
"fr-x-ipv4-212-195-148-209" might be French as spoken by a user of that
particular IP address, if you think such a thing would be useful and
interoperable.

Semantic expressiveness is not the same as syntactic anarchy.  Saying
"you can put anything you like in a private-use subtag" is not the same
as saying "... using whatever characters strike your fancy."

> If you can seriously document this I will drop my demand.

I think I have done so.

>> We have discussed these arguments and reached a decision; let us move
>> on.
>
> Can you document that long and interesting discussion?

It's not my responsibility to "document" WG discussions.  There is a
public archive for that.  The period of July 14-15 featured several
messages with the title "Compatibility" or "Compatibilities" that dealt
with this topic.  (Whether anyone finds them "interesting" is another
matter.)

> We are in Last Call. Those who do not support your decision are
> supposed to oppose it.
> This applies to the comments of Randy and Addison and to the silence
> of Martin.

There is no requirement that every WG member, silent or vocal, must
belong to either a "support" or "oppose" camp on every topic.  Members
who remain silent on a particular subject do so for a reason: they are
showing that they have no strong opinion and are choosing not to get
involved with it.

When the time comes to discuss the matching draft in detail, I will
probably have very little to say, because matching isn't one of my areas
of expertise or great interest, and I don't want anyone to interpret my
silence as an implicit show of support for or opposition to anything.
If I support or oppose something, I will say so, and I would expect
others to do the same.

Later:

>> x-you-could-simply-string-together-any-addition-al-attribut-es-you-
>> like-as-long-as-they-are-broken-into-clusters-of-8-or-fewer-ascii-
>> characte-rs
>
> Is that your contemptuous joke? I am sure the IESG and IETF will love
> it. Or have you something serious to propose.

It is a non-serious example used to illustrate a serious point.  The
syntax for private-use subtags does not limit one's ability to use them
to express whatever one chooses to express, language-related or not.
See my "fr-" examples above for a higher degree of seriousness.

--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/

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

---

From: r&d afrac <[email-masked]>
Date: Thu, 28 Jul 2005 20:05:55 +0200

Dear Doug,
I thank you to have made this effort. I what follow I will refer to your/my 
format for simplicity's sake. I fully understand that your format is the 
format proposed by the two authors (with some ABNF tuning seeming still 
necessary) and you will understand that my format is an open vision 
representing (this is my function for 27 years) of any user centric 
architecture.

IMHO your effort is based upon a basic misunderstanding:
- you obviously try to genuinely permit my format ("my" as above)
- but you consider that such a private use will follow the logic of your 
("your" as above) formatting approach.

My approach does not want to respect your 8alphanum constraint, because 
that constraint may come from previous RFCs you want to respect and I do 
not give a damn about (never used them). So you consider "x-" as a way to 
introduce private subtags while forcing them to obey your conventions, I 
consider "x-" as a way to escape from the arbitrary constraints of "your" 
format without confusing it.

At 17:21 28/07/2005, Doug Ewell wrote:
>"Competition" is not the word I would have chosen.  "Opposition" is more

My reading is that you consider us as competition and wants to exclude me.
I certainly oppose that attempt, but we respect your right to fairly develop.

("You/me" as indicated above)

>parsers that conform to RFC 3066.

I am afraid you get confused here.
I assume that what you want to say is:
1. no private use scheme can ever assure that it will not conflict with 
another private-use scheme (your text)
2. the current draft does prevent conflicts with existing parsers that 
conform to RFC 3066 except for the private use part (that part added 
otherwise we would loop).

Point 1 is where I object. It simply means that the Draft is not finished. 
You have two options to finish it:
- to devise a solution which will protect against private use schemes (such 
as relating the x- usage to an unique identifier of the private name space 
organiser). This way you will definitely prevent conflicts, but you will 
have to write the framework RFC I call for.
- to permit others to organise that warranty. This way you can complete the 
Draft today in removing the 8alpha constraints which makes such an 
organisation impossible.

Point 2 is where the Charter objects. The charter is to enhance RFC 3066. 
What you do here is to refuse to enhance RFC 3066 on a point which is going 
to be the main contentious point.

>and make sure each piece consists of 8 or fewer characters in the range

!!!
1. The colons, full stops etc _are_ part of the format.
2. each label by nature does not want to consist of 8 or fewer hexatridecimal.

You want to impose your vision to my private vision.

(I recall that "you" here are members  of this WG and "me" is the rest of 
the world less those supporting "your" vision).

>x-schemes-name-subname-address-date-etc

To make you understand in your own approach, let assume I have:

- a table of languages defined at jefsey-languages.com
- conforming to the scheme documented at language-tags.x-tags.com
- updated on 2005/12/03 at 16:08:09 (A).

I may want to adopt the langtag 
"x-language-tags.x-tags.com:singapourien.jefsey-languages.com:20051203160809A"

1. do you have any objection? On which grounds?

2. please give a secure transcription which will not confuse with another 
tag based upon:

- table of language defined in jefsey.com
- conforming to the scheme documented on tags.afrac.org
- documented on 2005/01/18

3. please indicate the format if the development environment is in Arabic.

4. please indicate how I can use a simple privarted URI/IRI for a subtag? 
Fun that a WG Chaired by Martin Duerst opposes the support of URI/IRI.

5. same with an handle. After Larry Roberts being refused a parameter, 
would Bob Khan be banned from languages documentation :-)

6. Same with OID - fun that I cannot use 1.3.6.1.4.1.311 in the IANA 
designed format because Peter Constable lead WG would have opposed :-) to 
be used by an Harald Alvestrand mailing list for IANA registrations .... 
(for those who want to know better http://www.alvestrand.no/objectid/top.html )

etc.

>There is no freely available coding standard for 20,000 languages,

who said "freely". I understand then why you prefer speaking of 
"opposition" rather than "competition". The same as there are 
commercial  projects based on ISO 639-3; there are others based upon ISO 
639-6, and there are others based upon other compilation efforts more 
organised  towards networked usages.

>  but you can put anything you like in a private-use subtag, including
>regional detail down to latitude and longitude.

Oh! I am not sure anyone will consider that except a few cases. But you are 
right, everything must be supported.

>   "fr-FR-x-VER" might be

You know what? People in here will certainly far more understand 
"x-français-versailles". I do not know why :-)
And they will use "x-" as an initial indicator only after being educated. 
Otherwise they will totally disregard your langtags.

>particular IP address, if you think such a thing would be useful and

As documented many times, CRC Access Grids are IPv6 based (I translate: 
common reference centres access grids are lists of IPv6 Interface ID to add 
to the user's host IPv6 address). How do you propose I write the IPv6 
address "2001:921F:9E51::1278:987E"?

You imagine the fun at IESG when I will document that the Draft has decided 
not to be compatible with IP¨v6 addresses (32 Hexa plus 7 colons, ie 39 
alpanum and colon)

>as saying "... using whatever characters strike your fancy."

You confuse your syntax and your semantic. You have to chose: either the 
private use space is private or it is not. If in your mind it is private 
(and therefore free) we can cooperate. If it is not, we will have to block you.

> > If you can seriously document this I will drop my demand.

I do not doubt you were serious, but I doubt you will say that at this 
stage your answer seriously document an proposition matching my needs.

>with this topic.  (Whether anyone finds them "interesting" is another

Thank you for this and for the comment.
The first part will probably be appreciated in appeal.
The second unfortunately denotes a possible contempt.

Everyone in here should realise that it could be so simple to fight "your" 
proposition as commercial, biased, exclusive, politically oriented, etc. I 
do not. I try to find a solution permitting to coexist and for your 
commercial interest to develop however I find them inappropriate and 
harming the Internet architecture and Global Community Interests.

>belong to either a "support" or "oppose" camp on every topic.

True. And this is why the x- 8aphanum being opposed, it is the duty of the 
WG-Chairs to make sure that there is a rough consensus in supporting it. 
This rough consensus must be expressed by support or whatever means the 
WG-Chairs may feel it exists. Once they have decided it, which is their 
privilege, they will however have to document it in front of IETF, IESG and 
IAB.

>Members who remain silent on a particular subject do so for a reason: they 
>are showing that they have no strong opinion and are choosing not to get 
>involved with it.

True. Thank you for mentioning it yourself. You document that there is no 
strong opinion in supporting "x- 8alphanum", and that most choose not to 
get involved in having it in the Draft. I fully understand this as I think 
it is a technical absurdity, and exclusion attempt and only a way to 
support a commercial exclusive or dominance, but this is only "my" opinion ...

>If I support or oppose something, I will say so, and I would expect

Fair enough. And I think everyone wants the same.

>See my "fr-" examples above for a higher degree of seriousness.

We can seriously agree "it is a non-serious example used to illustrate a 
serious point" (this is a deadly serious point. Your example is not 
serious) even if we probably do not understand it the same way.

This should only help us to find a way to make it a serious example to 
illustrate a serious point. Today the only way I found is to remove 
limitations on "x-" field, treating it as a normal regular escape sequence 
(what does not prevent to say that if one wants to stay compatible with RFC 
3066 old format, 8alphanum MUST be used). Or to chose "0-" as an open 
sequence (zero to be script independent).

I do not see any problem and you should not either with:

"0-language-tags.x-tags.com:singapourien.jefsey-languages.com:20051203160809A-2001:879:98F6::789C:1236"

jfc

---

From: Erkki Kolehmainen <[email-masked]>
Date: Fri, 29 Jul 2005 15:28:20 +0300

Dear Jefsey,

re your note of 28.7.2005 to Doug Ewell, the following quotation is to 
me an undisputable hard fact:
  No private-use scheme can ever assure that it will not conflict with 
another private-use scheme.  That is why they are private! [DE]
... and the following highly commendable:
  The scheme proposed in the current draft does prevent conflicts with 
existing parsers that conform to RFC 3066. [DE]
... and the following highly questionable:
  My approach does not want to respect your 8alphanum constraint, 
because that constraint may come from previous RFCs you want to respect 
and I do not give a damn about (never used them). [JM]

To all: In case it is not clear from my participation in this group, I 
have read the draft and support it.

Sincerely,
Erkki I. Kolehmainen

---

From: r&d afrac <[email-masked]>
Date: Fri, 29 Jul 2005 16:36:02 +0200

Dear Erkki,
as I noted it:

At 14:28 29/07/2005, Erkki Kolehmainen wrote:
>Dear Jefsey,
>re your note of 28.7.2005 to Doug Ewell, the following quotation is to me 
>an undisputable hard fact:

This pure non-sense!

The fact that they are private and they permit conflict are orthogonal. 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.

I am only sorry that you comment Doug remarks and my remark on its 
proposition, rather than the answer I made Doug requested. I understand 
why, but so will IETF/IESG/IAB/GAC/WTO/IANA. I would be interested in your 
comment on the problem rather than a repetition of your ideas.

> existing parsers that conform to RFC 3066. [DE]

The "highly commendable" is an odd hyperbole. It is correct, or it is not.

It is correct only if private use is removed from RFC 3066. The current 
draft does NOT prevent conflicts with existing parser that conform to RFC 
3066 in the private area. This is precisely this claim which is wrong, 
which is objected by  the previous claim above (you cannot say both: there 
will always be conflicts and at the same time you prevent conflicts). This 
reality is not an enhancement called by the Charter.

>not give a damn about (never used them). [JM]

May I ask why is that "highly questionable"? I tend to think that liberty 
is an highly questionable issue.

But in standards, you can say (what I detail and you totally ignore): "you 
MUST not (religious) say that!", or you can say "ok, what shall we then do?".

>have read the draft and support it.

Noted. Always good to note than someone has understood the way IETF Last 
Calls work: in bringing positive support to questioned points. The problem 
now is with the co-Chairs. Do they consider and can document to the IETF, 
IESG, IAB (and will they help the lawyers in GAC, IANA, WTO):

- the WG actually covered the Charter without having proceeded to an 
evaluation of what the Charter calls for.
- they have obtained a document professional enough for a positive IETF 
last call, with all the specialised points they did not cover, all the 
missing definitions of what they discuss and without having reduced 
opposition to consensus it proposes.
- they have a consensus while the few objections I rose and documented (at 
their request) and did made seriously addressed yet, the mild support the 
Draft obtained from a small score of participants on a list of 60 WG-Members.

We are here in a search of a consensus. So, we are not really interested in 
what you support or not: we are interested in what to do for both of us to 
agree. I said the two simple things for that:

1. not to claim to replace RFC 3066. I do not make it a critical point for 
the user community however. RFC 3066 is an error. Replacing an error by 
another error is no big damage. It is however critical for the IETF to 
decide if it will document the Multilingual Internet or not, as no serious 
non-US industry aficionado will use that system. We are making IDNA again. 
Your decision, at the end of the day I am not concerned. I think Harald 
documented enough, and Brian Carpenter's responses and attitude seem to 
confirm, and this WG-ltru main topic of interest documented it: IETF is 
simply not able to understand the problem and should not get into it.

I think that if this is the attitude, some wording should be reviewed by 
the authors, to protect their future pride.

2. no to use a joke to exclude the real world. This joke uses  two 
elements: "x-" and "8alpha". They are orthogonal. There can be three 
responses to that:

- either to make "x-" free from limitations. You oppose: it is not 
compatible to RFC 3066. I say I do not care (I am the user) but you want to 
force me to do what you want. For my good sake, so I stay compatible with 
the past I never had.

- either to create "0-" as a new zero constraint area. This has no problem 
of retrofit. The only opposition could be that the authors lose their grip 
on language tags and industry. But they claim they are not commercially and 
politically biased. So there is definitely no problem.

- either to keep the existing text to make sure it will probably never be 
used. The inconvenience for some will certainly be real, and the load 
imposed on us to oppose will be heavy. But the protection granted to many 
many more is worth it. All the more than Liberty does not mean for us to 
win anytime soon, or even to win. Just to delay the mistake until the 
better solutions we work on have taken off and the existing other solutions 
which are not aware of the threat have been informed (I note that since 
this Draft claims to be compatible with RFC 3066, nothing impeach the W3C 
to make it a W3C document tomorrow, or the IESG to make it a complement to 
RFC 3066 as we propose it).

I would not want to be in Randy and Martin shoes today. "0- or not 0-"
jfc

---

From: Martin Duerst <[email-masked]>
Date: Sat, 30 Jul 2005 16:00:32 +0900

>This pure non-sense!

No, it's not.

Domain names are not private. There is, as far as I know, no 'private use' domain
in the global DNS.
There are domains that are delegated, to CCTLDs, to organizations, and so on, and
within these, these entities may further delegate. That's not at all the same
as private use.

Private use, in the DNS, would mean e.g. that a .private domain is created,
where anybody could input their own subdomains without a central check.
Two different entities could both create mydomain.private. In DNS, this
is of course possible in local experiments (so it's truely private), but
not in the globally visible DNS.

If you want careful delegation for language tags, then what you need to
do is to create some careful proposal and apply for a one-letter prefix
(other than x).

 >I am only sorry that you comment Doug remarks and my remark on its 
proposition, rather than the answer I made Doug requested.

Last call is not about having questions answered, it is about making
comments, usually with concrete suggestions for improval.

 >I understand why, but so will IETF/IESG/IAB/GAC/WTO/IANA. I would be 
interested in your comment on the problem rather than a repetition of your ideas.

The above sentence refers to syntactical conflicts. The earlier sentence
refers to usage conflicts. These are different things.

 >
 >But in standards, you can say (what I detail and you totally ignore): 
"you MUST not (religious) say that!", or you can say "ok, what shall we 
then do?".

 >- they have a consensus while the few objections I rose and documented 
(at their request) and did made seriously addressed yet, the mild support 
the Draft obtained from a small score of participants on a list of 60 WG-Members.
 >
 >We are here in a search of a consensus. So, we are not really interested 
in what you support or not: we are interested in what to do for both of us 
to agree.

To be exact, rough consensus. This does not mean that everybody has
to agree.

 >I said the two simple things for that:
 >
 >1. not to claim to replace RFC 3066. I do not make it a critical point 
for the user community however. RFC 3066 is an error. Replacing an error by 

I think there are three different goal that one may look at:

1) a system that allows everybody to use their language(s)

2) a system that allows to tag any language in use, in a way for
    others (humans and systems) to determine that language

3) a system that allows anybody to to create tags they personally
    like to tag any language

1) is mostly possible now (with the exception of some languages for
    which scripts or letters are not yet encoded, which is an extremely
    low percentage of users, and is being worked on (mostly by the
    Unicode consortium))

2) is what this WG is about. With all the extensibility, my understanding
    is that we have a very good base.

3) may be what you want. It may sound great, but it's not helpful
    for interoperability, and it's not a goal for this WG (although
    with private tags, it's actually possible with the current draft).

There is of course nobody claiming that it is forbidden to anybody to
create language tags (or any other tags) to their liking. But

You are not *the* user. You are one of many users.

 >- either to create "0-" as a new zero constraint area. This has no 
problem of retrofit.

Is it allowed by the RFC 3066 grammar?

 >The only opposition could be that the authors lose their grip on language 
tags and industry. But they claim they are not commercially and politically 
biased. So there is definitely no problem.
 >I would not want to be in Randy and Martin shoes today. "0- or not 0-"

I'm wearing sandals today, and am feeling well in them :-).

Regards,    Martin.