status of RFC 3066 or RFC 3066bis in relation to
dewell at adelphia.net
Sat Mar 25 07:20:26 CET 2006
Mark Crispin <mrc at CAC dot Washington dot EDU> wrote:
> Suppose there are three RFC 2616 implementations:
> . implementation A uses RFC 1766
> . implementation B uses RFC 3066
> . implementation C uses RFC 3066bis
> Do these three implementation interoperate with each other? Does
> the expected behavior happen?
> Quite frankly, if 1766 -> 3066 -> 3066bis causes a NO, then the WG did
> not do its job. Nor did the IESG.
Clarification: The word "uses" here must be interpreted as "uses fully
and conformantly," otherwise the remainder of Mark's model does not
This means that in the case of our old friend, the network printing
protocol that implements only part of RFC 1766, neither the WG nor the
IESG can be held culpable for not maintaining that protocol's
restriction to only 2-letter language-only tags or 2-dash-2
The syntax of RFC 1766 allows any tag permissible under RFC 3066bis, and
more: ("en-a-b-c" would be valid under 1766, if registered.)
The syntax of RFC 3066bis allows any tag that could be generated under
RFC 1766 or 3066, or any tag registered for use with 1766 or 3066 up to
the date of publication of 3066bis.
A protocol that claims to "use RFC 1766" but does not support "no-bok"
or "no-nyn", which were registered less than a year after 1766 was
published, or "i-mingo" or "i-default" or 19 other tags that were
registered before 3066 was published, does not truly use RFC 1766. It
uses a subset, and the successors to 1766 cannot be responsible for
compatibility with every custom subset that someone may have defined.
And no, I am not blaming the innocent end users for the defects or
limitations of the protocol they are using.
McDonald, Ira <imcdonald at sharplabs dot com> wrote:
> Peter - I think you're on your own - and note that RFC 1766
> doesn't exactly gracefully prepare programmers for 'script'
> subtags in the second position followed by 'region' subtags
> in the third position - quoting from page 2 of RFC 1766:
> The syntax of this tag in RFC-822 EBNF is:
> Language-Tag = Primary-tag *( "-" Subtag )
> Primary-tag = 1*8ALPHA
> Subtag = 1*8ALPHA
> In the first subtag:
> - All 2-letter codes are interpreted as ISO 3166 alpha-2
> country codes denoting the area in which the language is
> - Codes of 3 to 8 letters may be registered with the IANA by
> anyone who feels a need for it, according to the rules in
> chapter 5 of this document.
RFC 1766 also says, immediately following the part Ira quoted:
> The information in the subtag may for instance be:
> - Country identification, such as en-US (this usage is
> described in ISO 639)
> - Dialect or variant information, such as no-nynorsk or en-
> - Languages not listed in ISO 639 that are not variants of
> any listed language, which can be registered with the i-
> prefix, such as i-cherokee
> - Script variations, such as az-arabic and az-cyrillic
> In the second and subsequent subtag, any value can be registered.
That doesn't sound to me like script subtags in what we would now call
the second position were considered unthinkable; indeed, they were
Fullerton, California, USA
More information about the Ietf-languages