> 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? Simple: It means we're letting technical correctness get in the way of clarity. > 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). That assumption is incorrect. The diffrences are minor, but there are differences - a couple of things, like EHLO instead of HELO or periods in unquoted phrases, are allowed now, whereas lots of stuff that used to be allowed has been removed. The protocols don't even hahve the same names in common usage. The term "ESMTP" is often used to refer to the SMTP variant described in RFC 5321 (RFC 2821 is obsolete, BTW) that uses EHLO, and "SMTP" refers to the original RFC821 protocol. > 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. Fully interoperable? Not even close. A lot of stuff has been removed from RFC 5311. If someone attempts to use those RFC 821 features, things aren't going to interoperate. Now, the consensus is that those features are useless, dangerous, rarely if ever implemented, or sometimes all three, and we're are better off for their absence, but that doesn't make your assertion valid. > So for a large > part we are looking at a revised specification of the same single protocol, It is a revised specification and the *service* it provides remains the same. But the protocol has changed. Some things have been removed; other things have been added. There's fallback where it is necessary, but there are also cases where functionality has simply been removed. > 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). That would be an absolutely absurd requirement to impose. Full interoperability is far too high a bar. > 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. THat's also absurd and overly constaining. These choices aren't amenable to being codified as a fixed set of rules. Context has to be considered. > 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). This approach may indeed be appropriate in some cases. There are bound to be cases where it is inappropriate, though. > 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 Whereas, in the case of email, the vast majority of MTAs now support ESMTP and the *overwhelming* majority of MUAs support MIME. > 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. Well, I cannot speak to the issues surrounding TLS, but insofar as email goes, the lesson we finally learned is that you have to design for deployment. Like it or not, we don't operate in a "field of dreams". The reality here is "if you buuld it, nobody is going to give a shit without some damn good reasons". There were at least four attempts to upgrade message formats prior to MIME. THey all failed because every single one of them failed to give adequate consieration to deployment issues. > 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). Once again this is overly constraining. There are many MUSTs in email standards that are present to prevent operational issues from arising. Or to address potential security issues. And these often have nothing to do with interoperability - in fact I can think of several where interoperability was intentionaly traded off in order to get better operational characteristics or security. > 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". Another problem which for some reason hasn't plagued the base email specifications, the majority of which are at draft. Ned _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf