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

[Ned Freed]

> As a long-time IETFer:

> Typically, these matters are handled on an ad-hoc case-by-case basis in
> which common sense prevails.

> The razor in this case is "does something break?"  Most updates to IETF
> documents expand upon, or clarify, what was in the older document; they do
> not introduce an incompatibility.  If something is removed, that is
> generally because there is community concensus that it is bad juju.

> So, given RFC abcd that normatively references RFC efgh that has been
> obsoleted by RFC ijkl:
>   . can two RFC abcd implementations communicate with each other, and the
>     desired behavior happen, even though one uses RFC efgh and the other
>     uses RFC ijkl?

> If the answer is yes, then the question is effectively academic in nature.
> Sometime in the future, RFC abcd will have to be updated to reflect the
> change to RFC ijkl, but as it doesn't break interoperability it isn't
> urgent.  One might expect that old implementations will use RFC efgh and
> new implementations will use RFC ijkl.

> If the answer is no, then someone was not doing their job; RFC ijkl should
> not have been approved without that working group taking on the needed
> update to RFC abcd.  An important purpose of the IETF/IESG bureaucracy is
> to prevent something like this from happening.

> Hence the answer that since RFC abcd normatively refers to RFC efgh, it is
> RFC efgh that is used by an RFC abcd implementator.  It is, however,
> expected that people would tend to use RFC ijkl instead (if only because
> it has clearer wording and represents more modern understanding) -- and
> sooner or later, RFC abcd will be obsoleted by a RFC mnop that makes this
> change official.

> Equally important is that RFC ijkl should not have been approved for
> publication if it creates an incompatibility problem in RFC abcd, without
> also updating/obsoleting RFC abcd.

Full agreement on all points.

				Ned