status of RFC 3066 or RFC 3066bis in relation to HTTPAccept-Language

Doug Ewell dewell at
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 
language-country tags.

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
> <...snip...>
>   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
>         used.
>    -    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-
>          cockney
>     -    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 
expressly anticipated.

Doug Ewell
Fullerton, California, USA

More information about the Ietf-languages mailing list