[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 --
http://panda.com/mrc
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