Phillip Hallam-Baker wrote: > > The fact remains that RFC 821 has the STANDARD imprimatur and the better > specification that was intended to replace it does not. > > It seems pretty basic to me that when you declare a document Obsolete it > should lose its STANDARD status. But under the current system that does not > happen. > > This situation has gone on now for 15 years. Why would anyone bother to put > time an effort into progressing documents along the three step track when > most of the documents at the highest rank are actually obsolete? > > What does STANDARD actually mean if the document it refers to is quite > likely obsolete? To me it looks like "Obsolete: XXXX" has been used with quite different meanings across RFCs, and some current uses might be inappropriate. Although it's been more than two decades that I read rfc821 (and none of the successors), I assume that all those RFC describe _the_same_ protocol (SMTP) and not backwards-incompatible revisions of a protocol family (SMTPv1,v2,v3). I also would assume that you could implement an MTA with rfc2821 alone (i.e. without ever reading rfc821), that is still fully interoperable with an implementation of rfc821. So for a large part we are looking at a revised specification of the same single protocol, and the term "obsoletes" should indicate that you can create an implementation of the protocol based solely on a newer version of the specification describing it and remain fully interoperable with an implementation of the old spec when (at least when using the mandatory to implement plus non-controversial recommended protocol features). For RFCs that create backwards-incompatible protocol revisions, and in particular when you still need the old specification to implement the older protocol revision, there is *NO* obsoletion of the old protocol by publication of the new protocol. Examples where this was done correctly: IPv4&IPv6, LDAPv2&LDAPv3, HTTPv1.0&HTTPv1.1. A sensible approach to obsolete a previous protocol version is to reclassify it as historic when the actual usage in the real world drops to insignificant levels and describe&publish that move in an informational RFC (I assume that is the intent of rfc-3494). Examples of clearly inappropriate "Obsoletes: XXXX" are the TLS protocol revisions (v1.1:rfc-4346 and v1.2:rfc-5246) which describe backward-incompatible protocol revisions of TLS and where the new RFCs specify only the behaviour of the new protocol version and even fail to clearly identify the backwards-incompatible changes. And if you look at the actual use of TLS protocol versions in the wild, the vast majority is using TLSv1.0, there is a limited use of TLSv1.1 and very close to no support for TLSv1.2. (examples https://www.ssllabs.com/ssldb/index.html http://www.ietf.org/mail-archive/web/tls/current/msg06432.html What irritates me slightly is that I see this announcement https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=935&k2=34176&tid=1277751536 which is more of a bashing of existing and widely used versions of SSLv3 and TLS, instead of an effort to improve _one_ of the existing TLS protocol revisions and to advance it on the standards maturity level and make it more easily acceptable to the marketplace. Adding explicit indicators for backwards-incompatible protocol changes in rfc-5246 might considerably facilitate the assessment just how much changes are necessary to an implementation of a predecessor version of TLSv1.2. Btw. 7.4.1.4.1 Signature Algorithms extension appears to be a big mess and fixing it wouldn't hurt. MUST requirements in spec ought to be strictly limited to features that are absolutely necessary for interoperability _and_ for the existing market, not just nice to have at some time in the future. The only TLS extension that deserves a MUST is described in rfc-5746 (TLS extension RI). One of the reasons why some working groups recycling protocol revisions on proposed rather advancing a widely deployed protocol to draft is the "the better is the enemy of the good". -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf