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 <mrex(_at_)sap(_dot_)com> 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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf