< draft-ietf-yam-5321bis-smtp-pre-evaluation-02.txt		draft-ietf-yam-5321bis-smtp-pre-evaluation-03.txt >
	YAM Working Group J. Klensin		YAM Working Group J. Klensin
	Internet-Draft		Internet-Draft
	Intended status: Informational B. Leiba		Intended status: Informational B. Leiba
	Expires: July 25, 2010 Huawei Technologies		Expires: August 1, 2010 Huawei Technologies
	January 21, 2010		January 28, 2010
	Preliminary Evaluation of RFC5321, Simple Mail Transfer Protocol (SMTP),		Preliminary Evaluation of RFC5321, Simple Mail Transfer Protocol (SMTP),
	for advancement from Draft Standard to Full Standard by the YAM Working		for advancement from Draft Standard to Full Standard by the YAM Working
	Group		Group
	draft-ietf-yam-5321bis-smtp-pre-evaluation-02.txt		draft-ietf-yam-5321bis-smtp-pre-evaluation-03.txt
	Abstract		Abstract
	This memo is a preliminary evaluation of RFC 5321, Simple Mail		This memo is a preliminary evaluation of RFC 5321, Simple Mail
	Transfer Protocol for advancement from Draft to Full Standard. It		Transfer Protocol for advancement from Draft to Full Standard. It
	has been prepared by the The Yet Another Mail Working Group.		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		THIS INTERNET DRAFT IS NOT MEANT TO BE PUBLISHED AS AN RFC, BUT IS
	WRITTEN TO FACILITATE DISCUSSION WITH THE IESG.		WRITTEN TO FACILITATE DISCUSSION WITH THE IESG.
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on July 25, 2010.		This Internet-Draft will expire on August 1, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 36 ¶		skipping to change at page 2, line 36 ¶
	2.7. IESG Feedback . . . . . . . . . . . . . . . . . . . . . . . 6		2.7. IESG Feedback . . . . . . . . . . . . . . . . . . . . . . . 6
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
	5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 7		6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
	6.2. Informative References . . . . . . . . . . . . . . . . . . 7		6.2. Informative References . . . . . . . . . . . . . . . . . . 7
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 7		Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 7
	A.1. Changes from version -01 to -02 . . . . . . . . . . . . . . 7		A.1. Changes from version -01 to -02 . . . . . . . . . . . . . . 7
	A.2. Changes from version -00 to -01 . . . . . . . . . . . . . . 8		A.2. Changes from version -00 to -01 . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		Appendix B. Detailed Issues List . . . . . . . . . . . . . . . . . 8
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	A preliminary evaluation has been made of Simple Mail Tranfer		A preliminary evaluation has been made of Simple Mail Tranfer
	Protocol [RFC5321] by the Yet Another Mail (YAM) Working Group for		Protocol [RFC5321] by the Yet Another Mail (YAM) Working Group for
	advancing it from Draft to Full Standard. The YAM WG requests		advancing it from Draft to Full Standard. The YAM WG requests
	feedback from the IESG on this decision.		feedback from the IESG on this decision.
	1.1. Note to RFC Editor		1.1. Note to RFC Editor
	skipping to change at page 3, line 27 ¶		skipping to change at page 3, line 27 ¶
	2. Preliminary Evaluation		2. Preliminary Evaluation
	2.1. Document		2.1. Document
	Title: Simple Mail Transfer Protocol		Title: Simple Mail Transfer Protocol
	Link: http://tools.ietf.org/html/rfc5321		Link: http://tools.ietf.org/html/rfc5321
	2.2. Time in Place		2.2. Time in Place
	RFC2026: _"A specification shall remain at the Draft Standard level		RFC2026: _ "A specification shall remain at the Draft Standard
	for at least four (4) months, or until at least one IETF meeting		level for at least four (4) months, or until at least one IETF
	has occurred."_		meeting has occurred." _
	Published: October 2008		Published: October 2008
	2.3. Implementation and Operational Experience		2.3. Implementation and Operational Experience
	RFC2026: _"significant implementation and successful operational		RFC2026: _ "significant implementation and successful operational
	experience ... characterized by a high degree of technical		experience ... characterized by a high degree of technical
	maturity and by a generally held belief that the specified		maturity and by a generally held belief that the specified
	protocol or service provides significant benefit to the Internet		protocol or service provides significant benefit to the Internet
	community."_		community." _
	Confidence level: Very high.		Confidence level: Very high.
	Electronic mail (historically known as "netmail" before "email" came		Electronic mail (historically known as "netmail" before "email" came
	into common use) has been in active use in the Internet community		into common use) has been in active use in the Internet community
	since the early 1970s. Although many small adjustments and		since the early 1970s. Although many small adjustments and
	clarifications have been made, the basic transport protocol that is		clarifications have been made, the basic transport protocol that is
	now used has been changed in only two important ways since the		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		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		introduction of DNS-based mail routing with the MX record with RFC
	skipping to change at page 4, line 14 ¶		skipping to change at page 4, line 14 ¶
	negotiating optional services with RFC 1425 in February 1993.		negotiating optional services with RFC 1425 in February 1993.
	While many mail systems over the years have relied more on the		While many mail systems over the years have relied more on the
	robustness of receiving systems in the face of deviations (or		robustness of receiving systems in the face of deviations (or
	creative interpretations of RFC 821 language in spite of changes and		creative interpretations of RFC 821 language in spite of changes and
	clarifications over the last 27 years), the DRUMS WG work that		clarifications over the last 27 years), the DRUMS WG work that
	produced RFC 2821 [RFC2821] in April 2001 was largely an update to		produced RFC 2821 [RFC2821] in April 2001 was largely an update to
	clarify various provisions. With the exception of a very few edge-		clarify various provisions. With the exception of a very few edge-
	case clarifications and changes in requirements levels, systems that		case clarifications and changes in requirements levels, systems that
	conform to the combination of RFC 821 [RFC0821] and RFC 1869		conform to the combination of RFC 821 [RFC0821] and RFC 1869
	[RFC1869] (both Full Standards) conform to RFC 5321. Those		[RFC1869] (both Full Standards) conform to RFCs 2821 (April 2001) and
	differences represented existing practice when RFC 5321 was written		5321. Those differences represented existing practice when RFC 5321
	and have been well-tested and widely deployed.		was written and have been well-tested and widely deployed.
	2.4. Proposed Changes		2.4. Proposed Changes
	The YAM WG proposes making the following changes in a revision:		The YAM WG proposes making the changes listed below in a revision.
			That the working group will review or consider an issue means that
			when RFC 5321bis is submitted for IESG approval, either changes will
			have be made for that issue or the working group will provide the
			IESG a summary of why it decided not to.
	Terminology: There has been ongoing controversy about the		Terminology: There has been ongoing controversy about the
	terminology in RFC 5321 and especially changes made between 821		terminology in RFC 5321 and especially changes made between 821
	and 2821 or between 2821 and 5321. While we assume that 5321 is		and 2821 or between 2821 and 5321. While we assume that 5321 is
	adequate, the WG will review terminology as appropriate and may		adequate, the WG will review terminology as appropriate and may
	make some adjustments.		make some adjustments.
	Metalanguage: During and after IETF Last Call on 5321, some		Metalanguage: During and after IETF Last Call on 5321, some
	suggestions were made about how to make metalanguage productions		suggestions were made about how to make metalanguage productions
	easier to find and connect. A complete rewrite or restructuring		easier to find and connect. A complete rewrite or restructuring
	skipping to change at page 4, line 47 ¶		skipping to change at page 4, line 51 ¶
	Normative References: RFC 5321 is worded in a way that makes some		Normative References: RFC 5321 is worded in a way that makes some
	references normative that are not strictly required to be. The WG		references normative that are not strictly required to be. The WG
	will consider whether those rewordings are appropriate. In		will consider whether those rewordings are appropriate. In
	particular, the reference to RFC 821 will be moved to Informative		particular, the reference to RFC 821 will be moved to Informative
	because all normative uses have been removed.		because all normative uses have been removed.
	Existing Errata Reports: The working group will incorporate		Existing Errata Reports: The working group will incorporate
	corrections to accepted errata, as shown in the RFC Editor's		corrections to accepted errata, as shown in the RFC Editor's
	errata tool. Errata ID 1683 is currently the only such item. IDs		errata tool. Errata ID 1683 is currently the only such item. IDs
	1543 and 1851 are reported, but unverified; the working group will		1543 and 1851 are reported, but unverified; the working group will
	consider those.		consider those. See Appendix B for details.
	Small Editorial Errors: Clear up various small editorial errors,		Small Editorial Errors: Clear up various small editorial errors,
	e.g., the use of "SHOULD not" in one location. YAM issue tracker		e.g., the use of "SHOULD not" in one location. YAM issue tracker
	issues 5, 6, 9, 12, and 13 refer to issues of this sort. The		issues 5, 6, 9, 12, and 13 refer to issues of this sort. The
	working group will add others that may be identified in its		working group will add others that may be identified in its
	detailed review.		detailed review. See Appendix B for details.
	Clarifications: The working group will attempt to address things		Clarifications: The working group will attempt to address things
	that have ben identified as unclear in RFC 5321. YAM issue		that have ben identified as unclear in RFC 5321. YAM issue
	tracker issues 7, 8, 10, and 11 refer to issues of this sort.		tracker issues 7, 8, 10, and 11 refer to issues of this sort.
	There has been discussion of these on the mailing list, and the		There has been discussion of these on the mailing list, and the
	resolutions of each may or may not result in a change in the		resolutions of each may or may not result in a change in the
	document. In no case will clarification changes be significant		document. See Appendix B for details. In no case will
	enough to violate "Non-Changes", Section 2.5.		clarification changes be significant enough to violate "Non-
			Changes", Section 2.5.
	2.5. Non-Changes		2.5. Non-Changes
	The YAM WG discussed and chose not to make the following changes:		The YAM WG discussed and chose not to make the following changes:
	1. Complete revision, rearrangement, or reformatting of metalanguage		1. Complete revision, rearrangement, or reformatting of metalanguage
	(see #2 above).		(see #2 above).
	2. Any extensions that would violate the rules for Full Standard or		2. Any extensions that would violate the rules for Full Standard or
	otherwise require revisiting the approved interoperability report		otherwise require revisiting the approved interoperability report
	for RFC 5321.		for RFC 5321.
	3. A number of extensions and changes that would have imposed		3. A number of extensions and changes that would have imposed
	significant new requirements on SMTP, or that would have implied		significant new requirements on SMTP, or that would have implied
	incompatible changes, were proposed during both the DRUMS WG		incompatible changes, were proposed both during the DRUMS WG
	period and during the discussions that led to RFC 5321. In each		period (leading up to RFC 2821) and during the subsequent
	case, the authors were advised to prepare a specific Internet-		discussions that led to RFC 5321. In each case, the authors were
	Draft describing the change, convince the community to progress		advised to prepare a specific Internet-Draft describing the
	it to Proposed Standard, and then implement and deploy the change		change, convince the community to progress it to Proposed
	quickly enough to "catch up" with the progress that started with		Standard, and then implement and deploy the change quickly enough
	RFC 2821. The notion was that those changes could then be		to "catch up" with the progress that started with RFC 2821. The
	integrated with the progression at the same maturity level. It		notion was that those changes could then be integrated with the
	is important to note that, independent of any constraints imposed		progression at the same maturity level. It is important to note
	by the YAM charter design, none of those proposals have appeared		that, independent of any constraints imposed by the YAM charter
	and been progressed even to IETF Last Call.		design, none of those proposals have appeared and been progressed
			even to IETF Last Call.
	4. As agreed when RFC 5321 was reviewed, the examples will not be		4. As agreed when RFC 5321 was reviewed, the examples will not be
	revised to bring them into alignment with RFC 2606 (BCP 32)		revised to bring them into alignment with RFC 2606 (BCP 32)
	conventions (example.com, etc.). The issues are explained in		conventions (example.com, etc.). The issues are explained in
	Section 1.3 of RFC 5321. The community also noted at the time		Section 1.3 of RFC 5321. The community also noted at the time
	that the relevant examples have been in use, substantially		that the relevant examples have been in use, substantially
	unchanged, for more than a quarter-century with no serious claims		unchanged, for more than a quarter-century with no serious claims
	of confusion or other harm being caused.		of confusion or other harm being caused.
	5. The Security Considerations section was extensively reviewed last		5. The Security Considerations section was extensively reviewed last
	skipping to change at page 8, line 15 ¶		skipping to change at page 8, line 15 ¶
	A.2. Changes from version -00 to -01		A.2. Changes from version -00 to -01
	o Added Security Considerations and Examples to the "no change" list		o Added Security Considerations and Examples to the "no change" list
	in Section 2.5.		in Section 2.5.
	o Identified RFC 821 as a specific reference to be moved from		o Identified RFC 821 as a specific reference to be moved from
	Normative to Informative.		Normative to Informative.
	o Add blanket placeholder for changes due to small editorial errors.		o Add blanket placeholder for changes due to small editorial errors.
			Appendix B. Detailed Issues List
			What follows are abbreviated details of the errata and tracker issues
			at the time of this writing, along with URLs to the actual entries.
			They are provided here to make it easier for IESG members -- and
			others -- to review them. If your browser does not automatically
			turn URLs into clickable links, copy/paste should still be
			convenient.
			Errata ID 1543: In section 3.8, client should treat a closed
			connection as a 451 response, not as 421 (current).
			http://www.rfc-editor.org/errata_search.php?rfc=5321
			The working group will consider this item. Discussion so far
			leans toward not making the change.
			Errata ID 1683: In section 4.4, missing repeat in grammar for
			Additional-Registered-Clauses.
			http://www.rfc-editor.org/errata_search.php?rfc=5321
			This item has been accepted, and the working group will make a
			change for it.
			Errata ID 1851: In section 4.1.1.5, text specifying server behaviour
			on a closed connection is misplaced, and should be in section
			4.1.1.10 or section 3.8.
			http://www.rfc-editor.org/errata_search.php?rfc=5321
			The working group will consider this item.
			Tracker Issue 5: In section 6.1, reword "next subsection" to specify
			the section number, for clarity.
			http://trac.tools.ietf.org/wg/yam/trac/ticket/5
			This item suggests an editorial change, and the working group will
			consider it.
			Tracker Issue 6: In section 4.4, there is extraneous text that
			should be removed or corrected (probably a paste error).
			http://trac.tools.ietf.org/wg/yam/trac/ticket/6
			This item documents an editorial error, and the working group will
			make a change for it.
			Tracker Issue 7: In section 2.2.2, add a bullet saying "Future SMTP
			extensions SHOULD explicitly specify if they are valid on the
			Submission port."
			http://trac.tools.ietf.org/wg/yam/trac/ticket/7
			The working group will consider this item.
			Tracker Issue 8: In section 4.1.1.3, remove text about source routes
			and move text about failed recipients here.
			http://trac.tools.ietf.org/wg/yam/trac/ticket/8
			The working group will consider this item.
			Tracker Issue 9: In section 3.9.2, there is extraneous text that
			should be removed or corrected (probably a paste error).
			http://trac.tools.ietf.org/wg/yam/trac/ticket/9
			This item documents an editorial error, and the working group will
			make a change for it.
			Tracker Issue 10: In section 3.9, add a subsection for "Backup MX"
			or "Plain forwarding".
			http://trac.tools.ietf.org/wg/yam/trac/ticket/10
			The working group will consider this item.
			Tracker Issue 11: In section 3.1, a server can offer two greeting
			codes to a new connection: 220 or 554. Clarify the semantics of
			the 554 code.
			http://trac.tools.ietf.org/wg/yam/trac/ticket/11
			The working group will consider this item.
			Tracker Issue 12: In examples, explicitly state that the examples
			will not be changed to use RFC 2606 domain names (such as
			example.com).
			http://trac.tools.ietf.org/wg/yam/trac/ticket/12
			This item suggests an editorial change, and the working group will
			consider it.
			Tracker Issue 13: In section 4.2.5, "SHOULD not" appears, with
			lowercase "not". The "NOT" should be in uppercase.
			http://trac.tools.ietf.org/wg/yam/trac/ticket/13
			This item documents an editorial error, and the working group will
			make a change for it.
	Authors' Addresses		Authors' Addresses
	John C Klensin		John C Klensin
	1770 Massachusetts Ave, Ste 322		1770 Massachusetts Ave, Ste 322
	Cambridge, MA 02140		Cambridge, MA 02140
	USA		USA
	Phone: +1 617 245 1457		Phone: +1 617 245 1457
	Email: john+ietf@jck.com		Email: john+ietf@jck.com
End of changes. 14 change blocks.
	29 lines changed or deleted		116 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/