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@av8.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