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

From: "Addison Phillips" <[email-masked]>
Date: Thu, 14 Jul 2005 15:18:40 -0700

I have performed the following editorial change in the editor's copy per Mark's email:

<t><spanx style="strong">Compatibility.</spanx> 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 ABNF and other provisions of RFC 3066 (such as those described in <xref target="XMLSchema"></xref>) 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.</t>

In other words, the phrase "based on the RFC 3066 ABNF" now reads:

"based on the ABNF and other provisions of RFC 3066"

~Addison

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 Mark Davis
> Sent: 2005年7月14日 14:40
> To: Randy Presuhn; LTRU Working Group
> Subject: Re: [Ltru] Compatibility (Was: Last call: Private UseTags)
> 
> 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
> implying that. So:
> 
> >    *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])
> [add: and the other specifications in the text of the RFC]
> >    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.
> 
> 
> ‎Mark
> 
> ----- Original Message -----
> From: "Randy Presuhn" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Thursday, July 14, 2005 12:07
> 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

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

---

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

Hi -

As a technical contributor, I can support the original wording
as well as the revised wording.

Randy

> From: "Addison Phillips" <[email-masked]>
> To: "Mark Davis" <[email-masked]>; "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Thursday, July 14, 2005 3:18 PM
> Subject: RE: [Ltru] Compatibility (Was: Last call: Private UseTags)
>
> <t><spanx style="strong">Compatibility.</spanx> 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 ABNF and other provisions of RFC 3066 (such as those described in <xref
target="XMLSchema"></xref>) 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.</t>
> > Sent: 2005?7?14? 14:40
> > ?Mark