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(_dot_)ietf(_dot_)org
[mailto:ltru-bounces(_at_)lists(_dot_)ietf(_dot_)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(_dot_)com>
To: "LTRU Working Group" <ltru(_at_)ietf(_dot_)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(_dot_)org>
To: "Peter Constable" <petercon(_at_)microsoft(_dot_)com>; "LTRU Working
Group"
<ltru(_at_)ietf(_dot_)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(_dot_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
Ltru(_at_)lists(_dot_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
Ltru(_at_)lists(_dot_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ltru