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