Message-Id: <6.2.1.2.2.20050728182357.049085d0@mail.afrac.org>
Date: Thu, 28 Jul 2005 20:05:55 +0200
To: "Doug Ewell" <dewell@adelphia.net>,
	"LTRU Working Group" <ltru@ietf.org>
From: r&d afrac <rd@afrac.org>
Subject: Re: [Ltru] Re: [psg.com #1072] compatibility and private use
  tags
In-Reply-To: <002601c59388$13799e60$030aa8c0@DEWELL>
References: <002601c59388$13799e60$030aa8c0@DEWELL>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Dear Doug,
I thank you to have made this effort. I what follow I will refer to your/=
my=20
format for simplicity's sake. I fully understand that your format is the=20
format proposed by the two authors (with some ABNF tuning seeming still=20
necessary) and you will understand that my format is an open vision=20
representing (this is my function for 27 years) of any user centric=20
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=20
("your" as above) formatting approach.

My approach does not want to respect your 8alphanum constraint, because=20
that constraint may come from previous RFCs you want to respect and I do=20
not give a damn about (never used them). So you consider "x-" as a way to=
=20
introduce private subtags while forcing them to obey your conventions, I=20
consider "x-" as a way to escape from the arbitrary constraints of "your"=
=20
format without confusing it.

At 17:21 28/07/2005, Doug Ewell wrote:
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.

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 deve=
lop.

("You/me" as indicated above)

> > 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.

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=20
another private-use scheme (your text)
2. the current draft does prevent conflicts with existing parsers that=20
conform to RFC 3066 except for the private use part (that part added=20
otherwise we would loop).

Point 1 is where I object. It simply means that the Draft is not finished=
.=20
You have two options to finish it:
- to devise a solution which will protect against private use schemes (su=
ch=20
as relating the x- usage to an unique identifier of the private name spac=
e=20
organiser). This way you will definitely prevent conflicts, but you will=20
have to write the framework RFC I call for.
- to permit others to organise that warranty. This way you can complete t=
he=20
Draft today in removing the 8alpha constraints which makes such an=20
organisation impossible.

Point 2 is where the Charter objects. The charter is to enhance RFC 3066.=
=20
What you do here is to refuse to enhance RFC 3066 on a point which is goi=
ng=20
to be the main contentious point.


> > 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]:

!!!
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 hexatridec=
imal.

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=
=20
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=20
"x-language-tags.x-tags.com:singapourien.jefsey-languages.com:20051203160=
809A"

1. do you have any objection? On which grounds?

2. please give a secure transcription which will not confuse with another=
=20
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?=
=20
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,=20
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=20
designed format because Peter Constable lead WG would have opposed :-) to=
=20
be used by an Harald Alvestrand mailing list for IANA registrations ....=20
(for those who want to know better http://www.alvestrand.no/objectid/top.=
html )

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,

who said "freely". I understand then why you prefer speaking of=20
"opposition" rather than "competition". The same as there are=20
commercial  projects based on ISO 639-3; there are others based upon ISO=20
639-6, and there are others based upon other compilation efforts more=20
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 a=
re=20
right, everything must be supported.

>   "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.

You know what? People in here will certainly far more understand=20
"x-fran=E7ais-versailles". I do not know why :-)
And they will use "x-" as an initial indicator only after being educated.=
=20
Otherwise they will totally disregard your langtags.

>"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.

As documented many times, CRC Access Grids are IPv6 based (I translate:=20
common reference centres access grids are lists of IPv6 Interface ID to a=
dd=20
to the user's host IPv6 address). How do you propose I write the IPv6=20
address "2001:921F:9E51::1278:987E"?

You imagine the fun at IESG when I will document that the Draft has decid=
ed=20
not to be compatible with IP=A8v6 addresses (32 Hexa plus 7 colons, ie 39=
=20
alpanum and colon)

>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."

You confuse your syntax and your semantic. You have to chose: either the=20
private use space is private or it is not. If in your mind it is private=20
(and therefore free) we can cooperate. If it is not, we will have to bloc=
k you.

> > If you can seriously document this I will drop my demand.
>
>I think I have done so.

I do not doubt you were serious, but I doubt you will say that at this=20
stage your answer seriously document an proposition matching my needs.

> >> We have discussed these arguments and reached a decision; let us mov=
e
> >> 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.)

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=
"=20
proposition as commercial, biased, exclusive, politically oriented, etc. =
I=20
do not. I try to find a solution permitting to coexist and for your=20
commercial interest to develop however I find them inappropriate and=20
harming the Internet architecture and Global Community Interests.

> > 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.

True. And this is why the x- 8aphanum being opposed, it is the duty of th=
e=20
WG-Chairs to make sure that there is a rough consensus in supporting it.=20
This rough consensus must be expressed by support or whatever means the=20
WG-Chairs may feel it exists. Once they have decided it, which is their=20
privilege, they will however have to document it in front of IETF, IESG a=
nd=20
IAB.

>Members who remain silent on a particular subject do so for a reason: th=
ey=20
>are showing that they have no strong opinion and are choosing not to get=
=20
>involved with it.

True. Thank you for mentioning it yourself. You document that there is no=
=20
strong opinion in supporting "x- 8alphanum", and that most choose not to=20
get involved in having it in the Draft. I fully understand this as I thin=
k=20
it is a technical absurdity, and exclusion attempt and only a way to=20
support a commercial exclusive or dominance, but this is only "my" opinio=
n ...

>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.

Fair enough. And I think everyone wants 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.

We can seriously agree "it is a non-serious example used to illustrate a=20
serious point" (this is a deadly serious point. Your example is not=20
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=20
illustrate a serious point. Today the only way I found is to remove=20
limitations on "x-" field, treating it as a normal regular escape sequenc=
e=20
(what does not prevent to say that if one wants to stay compatible with R=
FC=20
3066 old format, 8alphanum MUST be used). Or to chose "0-" as an open=20
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:20051203160=
809A-2001:879:98F6::789C:1236"

jfc


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru