ietf
[Top] [All Lists]

Re: motivations (was: Re: draft-housley-two-maturity-levels-00)

2010-06-28 10:35:14
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?


On Fri, Jun 25, 2010 at 4:35 PM, Yoav Nir <ynir(_at_)checkpoint(_dot_)com> 
wrote:

On Thursday, June 24, 2010 22:01 Phillip Hallam-Baker wrote:

<snip/>
We currently have the idiotic position where RFC821 is a full standard
and RFC2821 which obsoletes it is not.

Why is this idiotic. RFC 821 needed to be obsoleted. It had some features
that needed to be removed, and some things that may have been appropriate in
1982, but no longer so in 2001. "Proposed", "Draft" and "Full" refer to the
maturity of a standard, not to how well it fits the current Internet. One
could argue that 821 was very mature, because it needed a revision only
after 19 years.

Just because the old standard needs replacing, does not automatically mean
that the new standard is just as mature as the old one.

It does, however mean that the distinction is meaningless to implementers.
In 2001 or 2002 we would expect someone implementing SMTP to implement 2821,
a proposed standard, rather than 821, a full standard. While implementing a
full standard gives you more assurance about the quality of the spec, it
doesn't mean that "they" are not going to obsolete it ever.




-- 
Website: http://hallambaker.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf