> Date: 2004-12-18 23:37 > From: "Doug Ewell" <dewell@xxxxxxxxxxxx> > To: ietf-languages@xxxxxxxxxxxxx > > 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. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf