[rfc-i] Relation to other RFCs - Updates

Iljitsch van Beijnum iljitsch at muada.com
Thu May 3 13:39:10 PDT 2012


On 3 May 2012, at 18:43 , Martin Rex wrote:

> So if someone wants to newly implement TLSv1.0 in order to interoperate
> with the installed base of TLSv1.0, then the current RFC meta-data tells
> such an implementor that rfc2246 (TLSv1.0) has been "completely replaced"
> by rfc4346 (TLSv1.1) which again has been "completely replaced" by
> rfc5246 (TLSv1.2).  But this is clearly factually incorrect, because
> it will be impossible to implement TLSv1.0 from rfc5246(TLSv1.0).
> Instead, rfc2246 will be required (and rfc4346 & rfc5246 are
> entirely expendable for implementing TLSv1.0).

What we'd really need here is some branching where RFC Y that specifies version 1 replaces RFC X that specifies version 1 because the specification is improved but the protocol hasn't changed, while RFC Z specifies version 2 because the protocol is replaced by a new version.

In practice of course things aren't this simple, because apart from simple textual mistakes that generally don't warrant using up an additional RFC number, new RFCs pretty much never only improve the text and not the protocol.

There is of course a difference between an improvement of an existing protocol that completely obsoletes the old one because the old one was deficient in some way AND because the new version also works with implementations of the old version, and a completely new version that breaks compatibility.

I think HTTP solves this well with its major and minor version numbers:

>  HTTP/1.1 does not "Obsolete" HTTP/1.0

because it really should, as an HTTP 1.1 implementation is backward compatible with an HTTP 1.0 implementation.

Another interesting example is OSPF. The current specification for OSPFv2 is RFC 2328, which obsoletes 2178 -> 1583 -> 1247 -> 1131.

Note that RFC 1131 is OSPFv1, that OSPFv2 is not compatible with. (And, interesting for our purposes on this list, RFC 1131 is only available in Postscript format!)

Then there is OSPFv3: RFC 5340 which obsoletes RFC 2740 but NOT any of the previously mentioned ones, because OSPF versions 1 and 2 are IPv4-only and OSPFv3 is IPv6-only.

So it seems to me that in practice the current status language works well enough if applied carefully. Also, there is no reason why the first few words of an RFC should somehow be capable of explaining the intricacies of interdependency that exist between specifications. The only thing that's really necessary here is an M bit: more specifications follow.


More information about the rfc-interest mailing list