Show me a general-use RFC
3066 language tag which is too long to fit on an RFC
2822/3282 Content-Language header field line.
Your claim was that RFC 3066bis (the informal name we've been using for the
new draft) permits language tags that are longer than those permitted by RFC
3066. That is clearly false, as many people have pointed out. Any subsequent
niggling that particular *types* of language tags can be longer or not is
not relevant to the conformance implications of the two documents for
language tags. The new draft neither extends nor contracts the maximum
length of language tags conformant to RFC 3066.
Your claim that the RFC 3066 ABNF itself has a restriction in length is also
clearly false. I will quote that again since you seem somehow not to have
seen it:
"
The syntax of this tag in ABNF [RFC 2234] is:
Language-Tag = Primary-subtag *( "-" Subtag )
Primary-subtag = 1*8ALPHA
Subtag = 1*8(ALPHA / DIGIT)
"
Both documents establish many further limitations on the contents of
language tags in the text of each document. Ignoring those stated
limitations will, in both documents, result in nonconformant language tags.
Mark
----- Original Message -----
From: "Bruce Lilly" <blilly(_at_)erols(_dot_)com>
To: <ietf-languages(_at_)alvestrand(_dot_)no>
Cc: <ietf(_at_)ietf(_dot_)org>
Sent: Sunday, December 12, 2004 09:16
Subject: Re: New Last Call: 'Tags for Identifying Languages' to BCP
Date: 2004-12-11 00:52
From: "Mark Davis" <mark(_dot_)davis(_at_)jtcsv(_dot_)com>
To: ietf-languages(_at_)alvestrand(_dot_)no, ietf(_at_)ietf(_dot_)org
CC: ietf(_at_)ietf(_dot_)org
The ABNF is an expression of the grammar that
describes the set of all valid tags.
No, this is simply incorrect. You cannot expect that any implementation
that
simply does the ABNF is conformant.
I made no such claim. I do claim that if the ABNF
contradicts the normative text, as is the case in
your draft w.r.t. acceptance of several constructs
not permitted by RFC 3066 ABNF, that there is an
error in either the normative text or the ABNF.
There are a great many constraints on
the tags that are not in the ABNF grammar, that are clearly required in
any
reading of the text. Most of these *cannot* be encompassed in any ABNF
grammar.
If your claim is that the ABNF cannot express a
grammar consistent with the RFC 3066 ABNF, that
is clearly false.
There are a few that could be expressed in the ABNF; some at little
cost, some with a great deal of complication.
Are you claiming that it is unduly difficult to
make the ABNF match RFC 3066's?
This is not a technical
problem for the draft.
It is a problem due to the conflict between the
ABNF and the text. It is a problem because it
opens a loophole for future revisions to formalize
content which is incompatible with RFC 3066
implementations.
as reasonable as the current worst-case of 11 octets.
Also simply untrue. You seem not to be reading all the messages on this
subject. Look at the ABNF for RFC 3066. There is *no* limit in the ABNF
there!
The draft proposes closing RFC 3066-style registrations.
Show me a registered RFC 3066 language tag longer than
11 octets. Show me a general-use (i.e. not private-use)
RFC 3066 language tag which is too long to be used in an
RFC 2047/2231 encoded-word. Show me a general-use RFC
3066 language tag which is too long to fit on an RFC
2822/3282 Content-Language header field line.
_______________________________________________
Ietf-languages mailing list
Ietf-languages(_at_)alvestrand(_dot_)no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf