Subject: RE: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private UseTags

From: "Peter Constable" <[email-masked]>
Date: Wed, 13 Jul 2005 16:53:50 -0700

> From: [email-masked] [mailto:[email-masked]]
On Behalf Of
> Randy Presuhn

> Another message from Jefsey clearly intended for the WG mailing list.

> > >If you really believe issue #1061 needs to be re-opened,
> > >please identify the specific text in the draft you object to and
> > >the text you would propose in its place.
> >
> > "The use of "x-" has no particular meaning regarding the nature of
the
> > private subtags."

-1. The interpretation of this is unclear, and even if it were clarified
it doesn't appear to add anything significant.

> > or
> > "The use of "x-" is to introduce the private extension of the
format. It
> > may in particular be used for multilingual or punycoded subtags."
> >
> > The Alpha8 is discreminatory against internationalised subtags, as
punycode
> > can imply punycoded string of different length for internationalised
> > strings of similar length.

The use of Alpha and AlphaNum, which JFC considers a discriminatory
limitation, is nothing of the sort, and cannot be changed unless
backward compatibility is to be abandoned. Since there was consensus
from the outset that backward compatibility must be maintained, and
since it was clear from the last call back in December that backward
compatibility with protocols that consume RFC 3066 is essential, then I
think this is not open to reconsideration, and therefore this proposed
text cannot be accepted.

Thus, I think this issue can remain closed.

Peter Constable

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

---

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

At 01:53 14/07/2005, Peter Constable wrote:
>limitation,

I think there may be a confusion here in my typing. I consider what is 
discriminatory (and also absurd) the limitation of Alphanums to 8 bytes in 
x-tags.

>is nothing of the sort, and cannot be changed unless
>backward compatibility is to be abandoned.

I fully support the logic presented by F. Charles that this backward 
compatibility with something which never existed (since future x-tags are 
by nature ... future) is absurd. This is a good documentation of the 
religious opposition of this Draft to future and innovation.

>Since there was consensus
>from the outset that backward compatibility must be maintained,

Please reference the URL of this consensus. I make it a last call issue 
that such a backward "compatiblity" when non necessary is not to be introduced.

>and
>compatibility with protocols that consume RFC 3066 is essential,

1. as someone put it against me: December Last Call is over.
2. I was I think one of the most active during that Xmas Call....

>then I

"I think" is not a consensus. "I think myself" is not either. Only "we 
think" makes one.
I do not know if a text cannot be accepted due to your opinion. But I know 
that no one will think there a consensus against running code....

>Thus, I think this issue can remain closed.

If you mean the whole Draft, I think it could. But this would not change 
that the current work in many areas need a framework. I do not oppose a 
grasroots one, but I think that an adherence of IETF to that process would 
be of interest.
jfc

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 14 Jul 2005 12:07:19 -0700

Hi -

Jefsey (see below) writes "I make it a last call issue that such a backward
"compatiblity" when non necessary is not to be introduced".  In the context
of this discussion, and of previous discussions on this list, the issue appears
to be one of what is permitted by the ABNF.  In particular, I believe the question
is whether the WG wants the ABNF to permit the generation of tags which would
not have been permitted by the ABNF in RFC 3066.

The resolution of issues like #945 and #949 indicates that the WG places at least
some value on compatibility, and the comments indicate that there is strong interest
in ensuring that existing code will be able to syntactically cope with new tags.

However, just to remove all doubt, I'd like a hum on the following paragraph from
the registry draft's material on "goals":

   *Compatibility.* All RFC 3066 language tags  (including those in the
   IANA registry)  remain valid in this specification.  The changes in
   this document represent additional constraints on language tags.
   That is, in no case is the syntax more permissive and processors
   based on the RFC 3066 ABNF (such as those described in [XMLSchema])
   will be able to process the tags described by this document.  In
   addition, this document defines language tags in such as way as to
   ensure future compatibility.

Please indicate whether you agree or disagree with this goal.  A check
with http://tools.ietf.org/wg/ltru/draft-ietf-ltru-registry/ shows that this
material has been around for a while, modulo wordsmithing.

Randy, ltru co-chair

> From: "r&d afrac" <[email-masked]>
> To: "Peter Constable" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Thursday, July 14, 2005 5:28 AM
> Subject: [Ltru] Last call: Private UseTags
>

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 14 Jul 2005 14:40:28 -0700

The goal has always been present, and I think adding the paragraph is a
worthwhile clarification. I would make one change: the ABNF is not the only
constraint on the specification, and someone might read the paragraph as

>    based on the RFC 3066 ABNF (such as those described in [XMLSchema])
[add: and the other specifications in the text of the RFC]
>    ensure future compatibility.

‎Mark

---

From: r&d afrac <[email-masked]>
Date: Thu, 14 Jul 2005 23:22:26 +0200

Dear Randy,
I am extremely sorry, but I do not think the post below does not seem 
compatible, at least with a co-chair hat.

>in ensuring that existing code will be able to syntactically cope with new 

This is an opinion. It underlines that the consensus is on "at least some 
value on compatibility". This I agree, but not on a new "compatibility". 
That the consensus is a "strong interest".

>    ensure future compatibility.

May I remind this is a last call. And that due to the indications above 
there must be a consensus on adoption of this. And the silence is not support.

>material has been around for a while, modulo wordsmithing.

The lack of analysis of the Charter did not permit to evidence that the 
problem of RFC 3066 was the lack of organised flexibility. Adding rigidity 
is not appropriate. The RFC 3066 existing rigidity is a problem which is by 
nature as old as RFC 3066.

The real difficulty will be to have the IESG impose the text of a "Best 
Common Practices" against used running code and existing published and 
documented usage (http://rfc3066.org)
jfc

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 14 Jul 2005 18:06:07 -0700

Hi Jefsey -

If you disagree with the material on compatibility (which has been in the
i-d in various forms for a *long* time), then it is up to you to propose text.
However, I'd be surprised if the WG agreed to any substantial change
in that material.

If you have a problem with me as a co-chair, take it up with the ADs.

Randy

> To: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Thursday, July 14, 2005 2:22 PM
> Subject: Compatibilities
>

---

From: Martin Duerst <[email-masked]>
Date: Fri, 15 Jul 2005 11:01:39 +0900

[chair hat off]

I agree with the text below, moduo the changes proposed by Mark/
Addison ("based on the ABNF and other provisions of RFC 3066").

It is important to notice that for backwards compatibility,
tightening the ABNF can be done based on knowledge of existing,
registered, tags (as long as there are no additional restrictions
on private use tags, of which we don't know what's around), while
loosening of the ABNF and other restrictions would only be possible
with a very thorough search of existing applications, of which
there are just too many.

It is also important to notice that the fact that the backwards
compatibility provisions have been in 20 or so drafts is just
a sign of how important backwards compatibility is in many
engineering contexts. Whatever all the other details of the
draft, I doubt that any other charter or any other WG would
have done differently (of course, if the charter is to come
up with something new and incompatible, then that's a different
story).

I might also want to point out that the 8-letters-per-subtag
restriction isn't a real limitation for somebody e.g. wanting
to include punycode. It suffices to add the additional convention
that there is a hyphen after every eight letters. As an example,
JFC could create a language tag like:
x-jfc-punycode-n8jaaaaa-i5bhf7as-8fsfk3jn-knefdde3-fg11amb5-gzdb4wi9-bya3kc6l-ra
(the actual data is from a real punycode example at 
http://www.w3.org/2001/08/iri-test/; it doesn't make sense as a language
tag, but I hope it proves the point).

Regards,    Martin.

---

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

At 03:06 15/07/2005, Randy Presuhn wrote:
>i-d in various forms for a *long* time),

I know, Addison claimed that.

>then it is up to you to propose text.

You want me to add text to remove all the added text???
You should know now that the best compatibility I advise is to stay with 
RFC 3066  and its lose application.
What also permits the addition of the Draft.

Have a good night!
jfc

---

From: r&d afrac <[email-masked]>
Date: Fri, 15 Jul 2005 05:01:57 +0200

>tag, but I hope it proves the point).

Dear Martin,
you see the impact when I quote this during the IESG Last Call, explaining 
it is to fight existing running code "x-1en:dictionary.com"
jfc

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 15 Jul 2005 12:12:37 +0200

Randy Presuhn wrote:

> However, just to remove all doubt, I'd like a hum

Sure, all attempts to introduce a "sub-delimiter" in addition
to hyphen failed miserably, because they were _not_ backwards
compatible.  Dito ideas to use colon etc. in private subtags.

                           Bye, Frank