Hi Yoav,
At 00:36 27-06-10, Yoav Nir wrote:
Yes, but most of the RFC repositories, including
http://tools.ietf.org/html/rfc821 show "Obsoleted by: 2821" right
there at the top next to the word "STANDARD". Anyone looking
Yes.
at this RFC now (as opposed to 10 years ago) would immediately know
that while this *was* a standard, it is now obsolete.
If you then go to RFC 2821 and you will see that it is a Proposed
Standard which has been obsoleted by RFC 5321 (Draft
Standard). There are implementations out there that are STD 10
compliant. There are still a lot of implementations out there that
are RFC 2821 compliant. I'll ignore the differences between these
specifications. Most people mention RFC 2821 when it comes to
SMTP. Do I implement RFC 2821 or RFC 5321?
Let's try another example. RFC 4871 was published in May 2007 as
Proposed Standard. It was updated by RFC 5672 in August 2009. Do I
want to implement a specification that could be changed in two years
or do I stick to the Draft or Internet Standard for maturity?
This raises another question. What does "obsolete" mean? RFC 821
and RFC 2821 describe
It means that there is a newer version of the specification (RFC).
the same standard. Upgrading implementations to comply with RFC
2821 was not supposed to
break any connectivity. They describe the same protocol, so unless
you are interoperating with a peer that implemented some deprecated
features, you're good. OTOH,
In Section 3.3 of RFC 821:
"The VRFY and EXPN commands are not included in the minimum
implementation (Section 4.5.1), and are not required to work
across relays when they are implemented."
In Section 3.5.2 of RFC 2821:
"Server implementations SHOULD support both VRFY and EXPN."
In Section 3.5.2 of RFC 5321:
"Server implementations SHOULD support both VRFY and EXPN."
If I know which specification is widespread, I can decide whether I
should be able to rely on VRFY being available or not. It is also
unlikely that the VRFY is removed as the Standard is updated. If the
IETF decides to do that anyway, the specification is recycled at a
lower maturity level. In practice, it does not work like that for
reasons I won't get into.
It's true that under the current system RFCs never change. Even
advancing them to a higher level gives them a different number.
Actually no, the RFC only gets a different number if the text is changed.
I don't think there's any incentive to do so. RFC 4478 has been at
"Experimental" for 4 years, with at least 3 independent
implementations. But when I thought it was time to advance it to PS,
I was told (by an AD) "why bother?". It certainly didn't stop
implementers from implementing it.
If the specification has mind share, it will be implemented even if
the RFC is Experimental. If RFC 4478 fulfills the requirements for
PS, it could be advanced unless it can be shown that it is
technically unsound. The PS could mean that someone bothered to look
up the three independent implementations to see whether they are
interoperable. It might also help the author determine where the
text is clearly understood.
Also, it seems that in the last 4 years, the IETF has published only
3 full standards, 18 draft standards, and 740 proposed standards. I
think this tells us that there is very little incentive for
advancing a standard.
Or it might mean that the ADs are not interested in seeing the a
specification advanced through the standards track.
If there isn't any motivation to advance a "standard", we might as
well publish these RFCs as "Informational".
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf