> 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@xxxxxxxxx>
To: <ietf-languages@xxxxxxxxxxxxx>
Cc: <ietf@xxxxxxxx>
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.davis@xxxxxxxxx>
> > To: ietf-languages@xxxxxxxxxxxxx, ietf@xxxxxxxx
> > CC: ietf@xxxxxxxx
> >
> > > 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@xxxxxxxxxxxxx
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf