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

Mark Crispin mrc at CAC.Washington.EDU
Fri Mar 24 19:23:05 CET 2006

The best answer to your question is "does it matter?"

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?

If YES, then it doesn't matter.  Someday, an update to RFC 2616 will be 
published that uses RFC 3066bis (or whatever replaces it).

If NO, then RFC 1766 rules.  You have identified an urgent need for RFC 
2616 to be updated immediately.

If YES, then when you give a recommendation to a team, say "use RFC 
3066bis since that's the way of the future.  An RFC 1766 based version 
will work just fine against your code."

If NO, then say "don't implement RFC 2616.  It's broken."

Quite frankly, if 1766 -> 3066 -> 3066bis causes a NO, then the WG did not 
do its job.  Nor did the IESG.

On Fri, 24 Mar 2006, Peter Constable wrote:
> This still leaves things somewhat vague wrt the specific question I
> asked. You're saying that technically RFC 1766 is still the spec for
> Accept-Language, but it's expected that people will actually use 3066bis
> -- and as for "sooner or later", RFC 2616 was published in 1999, and RFC
> 3066 was published in 2001, so we've already had five years go by during
> which 2616 could have been obsoleted by another doc that normatively
> referenced 3066 but that hasn't happened.
> If I needed to give a recommendation to a team that has to deal with
> Accept-Language, it's really unclear to me which Language-Tag RFC I
> should point them to.

-- Mark --

Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

More information about the Ietf-languages mailing list