inline. I apologize in advance for so many questions. I have looked on the
ISOC site, and IAB site, and other pages to find the answers to these
questions.
On Wed, 4 Jun 2003, Harald Tveit Alvestrand wrote:
--On tirsdag, juni 03, 2003 17:28:55 -0400 Dean Anderson
<dean(_at_)av8(_dot_)com>
wrote:
You indicated that my criticism was incorrect regarding Mr. Klensin's
understanding of the standards process in regards to the description of
the current SMTP Standard. So, now I am confused, and would like to learn
how to correctly evalute the status of IETF Standards.
The following question seems simple enough:
"What is the current standard level RFC describing the SMTP protocol?"
formally, we have two standards-track specifications for the SMTP protocol.
RFC 821 at Standard, and RFC 2821 at Proposed Standard.
4.2.4 Historic
A specification that has been superseded by a more recent
specification or is for any other reason considered to be obsolete is
assigned to the "Historic" level. (Purists have suggested that the
word should be "Historical"; however, at this point the use of
"Historic" is historical.)
Note: Standards track specifications normally must not depend on
other standards track specifications which are at a lower maturity
level or on non standards track specifications other than referenced
specifications from other standards bodies. (See Section 7.)
Does RFC 2821 make up part of STD 10? It seems confusing, since STD 10
depends on RFC 821 which has been obsoleted by RFC 2821. By inference it
seems that STD 10 includes RFC 2821. Does this violate Section 4.2.4 of
RFC 2026?
Has RFC 821 been superceded by RFC 2821? If not, then how can RFC 821 be
obsolete?
It is confusing for RFC 821 can both be at "Standard" level and also
"Obsolete". Is the "Obsolete" notation on RFC 821 an error?
Further, RFC 2026 Section 4.1.1 recommends that "Proposed Standards"
should not be deployed into a "disruption-sensitive environment":
4.1.1 Proposed Standard
The entry-level maturity for the standards track is "Proposed
Standard". A specific action by the IESG is required to move a
specification onto the standards track at the "Proposed Standard"
level.
A Proposed Standard specification is generally stable, has resolved
known design choices, is believed to be well-understood, has received
significant community review, and appears to enjoy enough community
interest to be considered valuable. However, further experience
might result in a change or even retraction of the specification
before it advances.
Usually, neither implementation nor operational experience is
required for the designation of a specification as a Proposed
Standard. However, such experience is highly desirable, and will
usually represent a strong argument in favor of a Proposed Standard
designation.
The IESG may require implementation and/or operational experience
prior to granting Proposed Standard status to a specification that
materially affects the core Internet protocols or that specifies
behavior that may have significant operational impact on the
Internet.
A Proposed Standard should have no known technical omissions with
respect to the requirements placed upon it. However, the IESG may
waive this requirement in order to allow a specification to advance
to the Proposed Standard state when it is considered to be useful and
necessary (and timely) even with known technical omissions.
Bradner Best Current Practice [Page 12]
RFC 2026 Internet Standards Process October 1996
Implementors should treat Proposed Standards as immature
specifications. It is desirable to implement them in order to gain
experience and to validate, test, and clarify the specification.
However, since the content of Proposed Standards may be changed if
problems are found or better solutions are identified, deploying
implementations of such standards into a disruption-sensitive
environment is not recommended.
Our business customers with mission critical service requirements would be
concerned about using software which is not recommended for
"disruption-sensitive environments". Does the IETF recommend ignoring its
own warnings? If so, why have them? Do you think that introducing
"Proposed Standard" implmentations into disruption-sensitive environments
despite the warnings regarding use of Proposed Standards violates section
4 and section 14 of the ISOC Code of Conduct?
The intent is, I believe, that any RFC 2821 client will be RFC 821
compatible, but implementors who care should state which specification they
claim conformance to.
The criticisms documented by Dan Bernstein seem to suggest there are
considerable incompatibilites.
Implementors are not the only users of standards. Businsess seek to
purchase and sell "Standard" Services, and may receive just and public
criticism for not providing the services they claim to provide. In some
jurisdictions, this could conceivably be considered fraud, and/or unfair
trade practices. So if a business (SMTP client vendor, SMTP server
vendor, ISP, etc) claims to provide "Standard SMTP Service", and comply
with the "SMTP Standard", to which RFC should they be held accountable?
The "delete after 24 months" clause of RFC 2026 is inoperative in practice;
the oldest Proposed Standard is RFC 698, published in 1975.
If there is not agreement on the IESG (since 1975) to move an RFC to
"Draft Standard", nor to "Standard", then perhaps work on this proposed
standard should be terminated, and the proposed standard should be made
Historic, so that in the case of RFC 698, Telnet implementors are not
confused with irrelevant and inapplicable standards. Does this violate
section 4 and section 14 of the ISOC Code of Conduct?
Is the failure to carry out the procedures documented in RFC 2026 a
failure of either the IESG or the IAB? Is this a failure of the ISOC to
facilitate the legal and organizational issues concerning its conduct as
described in RFC 2031?
I have no explanation for the error in RFC 3300; the RFCs in question were
published by the RFC Editor without IETF review.
The first such document to refer to RFC 2821 was RFC 2800.
Should the text RFC 3300 be updated to eliminate this error? Is it
possible that the maturity status of RFC's could be changed by error?
Thank you for your attention,
Dean Anderson
President, Av8 Internet, Inc