The reason I chose RFC2821 is that there is really no basis on which the earlier document is better.
RFC821 was accepted when the process was far less stringent. The working group that produced 2821 was chartered to improve the documentation of SMTP rather than redesign the protocol. What people are asking for is that the transition from one standards state to another to actually mean something. If we think of the world as a huge collection of loosely coupled, probabilistic communicating finite state machines (similar to CSP but without rendezvous), I cannot think of any system in that world that would undergo a state transition on receiving the message RFC2821 has gone from DRAFT to STANDARD. Nor can I think of any system where the probability of a state transition would be affected by whether RFC2821 was in the one state or the other. What I and others conclude from this fact is that the current system as documented is broken. There is no point in fixing the practice to match the theory because the theory has been rejected FOR GOOD REASON. The current missmatch between theory and practice is hurting the IETF. I have been involved in the decision of where to take quite a few standards proposals now. And it must be said that the fact that nothing now becomes an IETF standard until the fact is irrelevant causes resistance. On Mon, Jun 28, 2010 at 3:35 PM, Martin Rex <[email protected]> wrote: > 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 > -- Website: http://hallambaker.com/
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
