New Last Call: 'Tags for Identifying Languages' to BCP

[Bruce Lilly]

>  Date: 2004-12-18 23:37
>  From: "Doug Ewell" <dewell at adelphia.net>
>  To: ietf-languages at alvestrand.no
>  
> Bruce Lilly <blilly at erols dot com> wrote:
> 
> >> If you can write a reasonable "grandfathered" production in ABNF that
> >> will allow this set of tags and no others, such that the ABNF can be
> >> used without also referring to the prose, then I salute you.
> >
> > If there really are only 24 items of less than 11 octets each,
> > a trivial solution is to simply list them (with the usual ABNF
> > syntax) as literal strings.  That should take no more than a
> > half-dozen lines.
> 
> Listing the 24 literal strings doesn't seem like a particularly elegant
> solution.

Perhaps it doesn't meet your subjective criteria for elegance.
But it is a *reasonable* production that meets specific criteria,
and that is what you asked for.  A list of specific literal
strings is not unusual (e.g. RFC 3464 sect. 2.3.3, RFC 3798
sect. 3.2.6, RFC 2156 (summarized in Appendix E)).

> Look, RFCs 1766 and 3066 both had ABNF that was insufficient to describe
> the range of valid language tags, and AFAIK they were not greatly
> criticized for this. [...] The same is true for RFC 3066bis.

A crucial difference is that RFC 3066 and 1766 required
registration before use, and community review before
registration.  If a tag were proposed that failed to meet
some criteria not adequately detailed in the ABNF, the
reviewer, the community, and the Area Director could
explain the issue *before* the darned thing went into use.
As that safety mechanism is being removed, it is more
important that the specification be clear and precise and
consistent.

> RFC 2231, which you have mentioned often in this thread, has the
> following as part of its ABNF:
> 
> -----begin pasted material-----
>    charset := <registered character set name>
> 
>    language := <registered language tag [RFC-1766]>
> -----end pasted material-----
> 
> If this type of syntax specification is good enough for RFC 2231, why
> wouldn't it be good enough here?

RFC 2231 isn't BCP and doesn't obsolete BCP; it does not
remove any registration requirements.  While it obsoletes
another RFC (2184), it does not attempt to incorporate
content of the obsoleted RFC or artifacts of its use by a
vague reference.  Reference to (unaffected) external
specifications is fine; the draft uses RFC 2234 productions,
for example, and that is not a problem.