YAM Working Group J. Klensin
Internet-Draft
Intended status: Informational B. Leiba
Expires: May 17, 2010 Huawei Technologies
November 13, 2009
Preliminary Evaluation of RFC5321, Simple Mail Transfer Protocol (SMTP),
for advancement from Draft Standard to Full Standard by the YAM Working
Group
draft-ietf-yam-5321bis-smtp-pre-evaluation-01.txt
Abstract
This memo is a preliminary evaluation of RFC 5321, Simple Mail
Transfer Protocol for advancement from Draft to Full Standard. It
has been prepared by the The Yet Another Mail Working Group.
THIS INTERNET DRAFT IS NOT MEANT TO BE PUBLISHED AS AN RFC, BUT IS
WRITTEN TO FACILITATE DISCUSSION WITH THE IESG.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 17, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Klensin & Leiba Expires May 17, 2010 [Page 1]
Internet-Draft YAM 5321bis Evaluation November 2009
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Note to RFC Editor . . . . . . . . . . . . . . . . . . . . 3
2. Preliminary Evaluation . . . . . . . . . . . . . . . . . . . . 3
2.1. Document . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Time in Place . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Implementation and Operational Experience . . . . . . . . . 3
2.4. Proposed Changes . . . . . . . . . . . . . . . . . . . . . 4
2.5. Non-Changes . . . . . . . . . . . . . . . . . . . . . . . . 4
2.6. Downward references . . . . . . . . . . . . . . . . . . . . 5
2.7. IESG Feedback . . . . . . . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 7
A.1. Changes from version -00 to -01 . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Klensin & Leiba Expires May 17, 2010 [Page 2]
Internet-Draft YAM 5321bis Evaluation November 2009
1. Introduction
A preliminary evaluation has been made of Simple Mail Tranfer
Protocol [RFC5321] by the Yet Another Mail (YAM) Working Group for
advancing it from Draft to Full Standard. The YAM WG requests
feedback from the IESG on this decision.
1.1. Note to RFC Editor
This Internet-Draft is not meant to be published as an RFC. It is
written to facilitate processing within the IESG.
2. Preliminary Evaluation
2.1. Document
Title: Simple Mail Transfer Protocol
Link: http://tools.ietf.org/html/rfc5321
2.2. Time in Place
RFC2026: _"A specification shall remain at the Draft Standard level
for at least four (4) months, or until at least one IETF meeting
has occurred."_
Published: October 2008
2.3. Implementation and Operational Experience
RFC2026: _"significant implementation and successful operational
experience ... characterized by a high degree of technical
maturity and by a generally held belief that the specified
protocol or service provides significant benefit to the Internet
community."_
Confidence level: Very high.
Electronic mail (historically known as "netmail" before "email" came
into common use) has been in active use in the Internet community
since the early 1970s. Although many small adjustments and
clarifications have been made, the basic transport protocol that is
now used has been changed in only two important ways since the
publication of RFC 821 in August 1982. One of those changes was the
introduction of DNS-based mail routing with the MX record with RFC
974 in January 1986 (with some small clarifications in RFC 1123 in
October 1979). The second was the introduction of a model for
Klensin & Leiba Expires May 17, 2010 [Page 3]
Internet-Draft YAM 5321bis Evaluation November 2009
negotiating optional services with RFC 1425 in February 1993.
While many mail systems over the years have relied more on the
robustness of receiving systems in the face of deviations (or
creative interpretations of RFC 821 language in spite of changes and
clarifications over the last 27 years), the DRUMS WG work that
produced RFC 2821 [RFC2821] in April 2001 was largely an update to
clarify various provisions. With the exception of a very few edge-
case clarifications and changes in requirements levels, systems that
conform to the combination of RFC 821 [RFC0821] and RFC 1869
[RFC1869] (both Full Standards) conform to RFC 5321. Those
differences represented existing practice when RFC 5321 was written
and have been well-tested and widely deployed.
2.4. Proposed Changes
The YAM WG proposes making the following changes in a revision:
Terminology: There has been ongoing controversy about the
terminology in RFC 5321 and especially changes made between 821
and 2821 or between 2821 and 5321. While we assume that 5321 is
adequate, the WG will review terminology as appropriate and may
make some adjustments.
Metalanguage: During and after IETF Last Call on 5321, some
suggestions were made about how to make metalanguage productions
easier to find and connect. A complete rewrite or restructuring
of the metalanguage should be avoided on the grounds that it would
carry a very high risk of introducing errors. Instead, resources
and tools permitting (significant manual work is now required),
the revised document will contain an index to productions and
where they are defined.
Normative References: RFC 5321 is worded in a way that makes some
references normative that are not strictly required to be. The WG
will consider whether those rewordings are appropriate.
2.5. Non-Changes
The YAM WG discussed and chose not to make the following changes:
1. Complete revision, rearrangement, or reformatting of metalanguage
(see #2 above).
2. Any extensions that would violate the rules for Full Standard or
otherwise require revisiting the approved interoperability report
for RFC 5321.
Klensin & Leiba Expires May 17, 2010 [Page 4]
Internet-Draft YAM 5321bis Evaluation November 2009
3. A number of extensions and changes that would have imposed
significant new requirements on SMTP, or that would have implied
incompatible changes, were proposed during both the DRUMS WG
period and during the discussions that led to RFC 5321. In each
case, the authors were advised to prepare a specific Internet-
Draft describing the change, convince the community to progress
it to Proposed Standard, and then implement and deploy the change
quickly enough to "catch up" with the progress that started with
RFC 2821. The notion was that those changes could then be
integrated with the progression at the same maturity level. It
is important to note that, independent of any constraints imposed
by the YAM charter design, none of those proposals have appeared
and been progressed even to IETF Last Call.
4. The Security Considerations section was extensively reviewed last
year (during the review and approval of RFC 5321). No evidence
has appeared since then that would require further review or
additional changes.
2.6. Downward references
At Full Standard, the following references would be downward
references:
RFC 5322 if 5322bis is not progressed simultaneously with 5321bis.
(This is not expected to happen.)
RFC 4291, IP Version 6 Addressing Architecture.
RFC 3848, ESMTP and LMTP Transmission Types Registration. Note
that it is possible to rephrase RFC 5321bis to avoid this
normative reference and the WG will consider doing that.
2.7. IESG Feedback
The YAM WG requests feedback from the IESG on this decision. In
particular:
o Does the IESG believe the proposed changes are suitable during a
move from Draft to Full Standard?
o Excluding the previous proposed changes and expected IESG support
for technically substantive IETF last call feedback, does the IESG
believe any additional changes are critical to advance this
document from draft to full standard? If so, please provide
sufficient information so the WG can address these issues prior to
IETF last call or determine that the document is inappropriate for
the YAM WG to process at this time.
Klensin & Leiba Expires May 17, 2010 [Page 5]
Internet-Draft YAM 5321bis Evaluation November 2009
o Does the IESG consider the downward references acceptable for a
full standard? If not, please cite which specific downward
reference or references are problematic and why so the WG can
address these issues prior to IETF last call or determine the
document is inappropriate for the YAM WG to process at this time.
3. IANA Considerations
This document contains no IANA actions.
4. Security Considerations
This document requests IESG feedback. There are no security
considerations.
5. Acknowledgments
This document was prepared from a template supplied by Subramanian
Moonesamy.
Some of the information provided in this document, but not provided
in the RFC 1652 evaluation (http://www.ietf.org/id/
draft-ietf-yam-rfc1652bis-pre-evaluation-00.txt), was inspired by
brief discussions with Pasi Eronen and Subramanian Moonesamy during
IETF 76.
6. References
6.1. Normative References
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
6.2. Informative References
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, August 1982.
[RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
November 1995.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
Klensin & Leiba Expires May 17, 2010 [Page 6]
Internet-Draft YAM 5321bis Evaluation November 2009
Appendix A. Change Log
A.1. Changes from version -00 to -01
o Added Security Considerations to the "no change" list in
Section 2.5.
Authors' Addresses
John C Klensin
1770 Massachusetts Ave, Ste 322
Cambridge, MA 02140
USA
Phone: +1 617 245 1457
Email: john+ietf@jck.com
Barry Leiba
Huawei Technologies
Phone: +1 646 827 0648
Email: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/
Klensin & Leiba Expires May 17, 2010 [Page 7]