Subject: RE: [Ltru] Compatibility (Was: Last call: Private UseTags)

From: "Addison Phillips" <[email-masked]>
Date: Thu, 14 Jul 2005 13:06:56 -0700

+1

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Randy Presuhn
> Sent: 2005?7?14? 12:07
> To: LTRU Working Group
> Subject: [Ltru] Compatibility (Was: Last call: Private UseTags)
> 
> 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
> >
> 
> > At 01:53 14/07/2005, Peter Constable wrote:
> > >The use of Alpha and AlphaNum, which JFC considers a discriminatory
> > >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
> > >since it was clear from the last call back in December that backward
> > >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
> > >think this is not open to reconsideration, and therefore this proposed
> > >text cannot be accepted.
> >
> > "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
> 
> 
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

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

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 14 Jul 2005 20:57:08 -0700

A single implementation created by the author of the comment is not evidence of compatibility or incompatibily. Make a fool of yourself if you wish...

Addison

Addison P. Phillips

> Behalf Of r&d afrac
> Sent: 2005?7?14? 20:02
> To: Martin Duerst
> Cc: [email-masked]
> Subject: Re: [Ltru] Compatibility (Was: Last call: Private UseTags)
> 
> On 04:01 15/07/2005, Martin Duerst said:
> >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).
> 
> 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
> 
> 
> 
> 
>