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

["Addison Phillips" <addison.phillips at quest.com>]

I agree that we should modify the text to include requirements imposed by RFC 3066 beyond those in the ABNF.

I should note that it isn't clear from Mark's note: this paragraph is already in the draft, in Section 8 (Changes from RFC 3066), and has been present since draft-langtags-05 (or, to put it another way, the past *FIFTEEN* drafts of the document). This requirement should not be a mystery to anyone at this point.

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: ltru-bounces at lists.ietf.org [mailto:ltru-bounces at lists.ietf.org] 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" <randy_presuhn at mindspring.com>
> To: "LTRU Working Group" <ltru at ietf.org>
> 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" <rd at afrac.org>
> > > To: "Peter Constable" <petercon at microsoft.com>; "LTRU Working Group"
> <ltru at ietf.org>
> > > 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
> > Ltru at lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/ltru
> >
> >
> 
> 
> 
> _______________________________________________
> Ltru mailing list
> Ltru at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
Ltru at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru