Preliminary Evaluation of RFC 1652 for Advancement to Full Standard
draft-ietf-yam-rfc1652bis-pre-evaluation-02

Abstract

This memo is a preliminary evaluation of RFC 1652 "SMTP Service Extension for 8bit-MIMEtransport" for advancement from Draft to Full Standard. It has been prepared by the The Yet Another Mail Working Group.

THIS INTERNET DRAFT IS WRITTEN TO FACILITATE PROCESSING WITHIN THE IESG. IT IS NOT MEANT TO BE PUBLISHED AS AN RFC.

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 June 4, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

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.

1.  Introduction

A preliminary evaluation has been made of SMTP Service Extension for 8bit-MIMEtransport [RFC1652] (Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, “SMTP Service Extension for 8bit-MIMEtransport,” July 1994.) 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

Title:

SMTP Service Extension for 8bit-MIMEtransport

Link:

http://tools.ietf.org/html/rfc1652

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:

July 1994

Confidence document meets RFC 2026 section 4.1.3 (Standard) test:

RFC2026:

"significant implementation and successful operational experience...[with] a high degree of technical maturity and [] a generally held belief that the specified protocol or service provides significant benefit to the Internet community."

In the 15 years since publication, this specification has become an integral part of all professional SMTP software products and is widely supported in Internet Mail operations. There are no RFC Errata on this specification.

The universal deployment of this feature is well-known to many YAM working group participants. In addition, the working group is obtaining explicit statements of deployment for specific SMTP implementations.

Proposed Changes (the YAM WG proposes making the following changes in a revision:

RFC2026:

"Minor revisions are expected, but a significant revision may require that the specification accumulate more experience at its current maturity level before progressing."

Remove reference to [RFC0974] (Partridge, C., “Mail routing and the domain system,” January 1986.)

Add reference to [RFC5321] (Klensin, J., “Simple Mail Transfer Protocol,” October 2008.). Use it to replace reference to [RFC0821] (Postel, J., “Simple Mail Transfer Protocol,” August 1982.).

Add reference to [RFC5234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.). Use it to replace reference to [RFC0822] (Crocker, D., “Standard for the format of ARPA Internet text messages,” August 1982.). This is for ABNF specification.

Add reference to [RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) and [RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.). Use them to replace [RFC1521] (Borenstein, N. and N. Freed, “MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies,” September 1993.).

Add reference to [RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.).

Remove reference to [RFC1651] (Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, “SMTP Service Extensions,” July 1994.). Replace it with reference to [RFC5321] (Klensin, J., “Simple Mail Transfer Protocol,” October 2008.).

Remove reference to [RFC1522] (Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text,” September 1993.)

In Section 3 of [RFC1652] (Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, “SMTP Service Extension for 8bit-MIMEtransport,” July 1994.) replace:

Finally, although the content body contains arbitrary lines of octet-aligned material, the length of each line (number of octets between two CR-LF pairs), is still subject to SMTP server line length restrictions (which may allow as few as 1000 octets on a single line). This restriction means that this extension MAY provide the necessary facilities for transferring a MIME object with the 8BIT content-transfer-encoding, it DOES NOT provide a means of transferring an object with the BINARY content-transfer-encoding.

with:

Finally, although the content body contains arbitrary lines of octet-aligned material, the length of each line (number of octets between two CR-LF pairs), is still subject to SMTP server line length restrictions (which can allow as few as 1000 octets, inclusive of the CR-LF pair, on a single line). This restriction means that this extension provides the necessary facilities for transferring a MIME object with the 8BIT content-transfer-encoding, it DOES NOT provide a means of transferring an object with the BINARY content-transfer-encoding.

Add an IANA Considerations section, to register this extension.

Non-Changes (the YAM WG discussed and chose not to make the following changes):

None.

Downward references (At Full Standard, the following references would be downward references):

[RFC5321] (Klensin, J., “Simple Mail Transfer Protocol,” October 2008.), [RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.), [RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.).

NOTE:

The YAM working group currently has the goal of also moving these documents to Full Standard.

3.  IESG Feedback

The YAM WG requests feedback from the IESG on these decisions. In particular:

• Does the IESG believe the proposed changes are suitable during a move from Draft to Full Standard?
• Does the IESG believe any other proposed changes are necessary to satisfy IESG requirements to advance to Full Standard?
• Does the IESG consider the downward references acceptable for a Full Standard?

4.  IANA Considerations

This document contains no IANA actions.

5.  Security Considerations

This document requests IESG feedback and does not raise any security concerns. Security considerations for RFC 1652 [RFC1652] (Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, “SMTP Service Extension for 8bit-MIMEtransport,” July 1994.) have been taken into account during the preliminary evaluation and appear in either Section 2.4 or Section 2.5 of this document.

6. Normative References

Author's Address