Network Working Group J. Klensin Internet-Draft October 18, 2004 Expires: April 18, 2005 Internet Standards Documentation (ISDs) - Examples draft-ietf-newtrk-sample-isd-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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 April 18, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract The proposal to define what is actually an IETF standard and to create ways of explaining and qualifying its applicability and relationship to other documents has been described in an Internet-Draft, "Internet Standards Documentation (ISDs)" (draft-ietf-newtrk-repurposing-isd-00). This document provides some examples of what such documents might look like. It includes a very complicated example (SMTP) and a fairly simple one (the IMAP/POP authorization specification of RFC 2195, which has not progressed Klensin Expires April 18, 2005 [Page 1] Internet-Draft ISD Examples October 2004 beyond Proposed Standard). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Observations on the Base Document . . . . . . . . . . . . . . 4 3. Example 1: The Simple Mail Transfer Protocol . . . . . . . . . 5 3.1 SMTP Comments . . . . . . . . . . . . . . . . . . . . . . 5 3.2 ISD xxxx: Simple Mail Transfer Protocol, SMTP . . . . . . 5 3.2.1 Documents making up the Standard, STD10 . . . . . . . 5 3.2.2 Additional Relevant Documents . . . . . . . . . . . . 6 3.2.3 Extensions to the SMTP Base Specification . . . . . . 6 3.2.4 Related ISDs (temporary) . . . . . . . . . . . . . . . 7 3.2.5 Experimental Extensions . . . . . . . . . . . . . . . 8 3.2.6 Comments on Related Documents . . . . . . . . . . . . 8 3.2.7 History and Tracking Information . . . . . . . . . . . 10 4. Example 2: POP/IMAP Authentication with CRAM-MD5 . . . . . . . 11 4.1 POP/AUTH CRAM-MD5 Comments . . . . . . . . . . . . . . . . 11 4.2 ISD yyyy: POP/IMAP Authentication with CRAM-MD5, CRAM-MD5 . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations and Other Boilerplate . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 6.2 Informative References . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Klensin Expires April 18, 2005 [Page 2] Internet-Draft ISD Examples October 2004 1. Introduction The proposal to define what is actually an IETF standard and to create ways of explaining and qualifying its applicability and relationship to other documents has been described in an Internet-Draft, "Internet Standards Documentation (ISDs)" [ISD-definition]. This document provides some examples of what such documents might look like. It includes a very complicated example (SMTP) and a fairly simple one (the IMAP/POP authorization specification of RFC 2195 [RFC2195], which has not progressed beyond Proposed Standard). It is worth stressing that little effort has been made to check most of the statements in the examples for accuracy; they were constructed from the author's (failing) memory only. If a successor to the ISD proposal document is ultimately approved, the examples here should evolve into actual ISD documents; this document itself is not expected to evolve into an RFC of any type. Due to some issues with tools (or the author's lack of familiarity with them), no attempt has been made to get the formating of the sample documents correct in this draft. I prefer the format used in Scott Bradner's treatment of the standards process document. What is here should be enough to stimulate a discussion of content; perhaps the format can be upgraded at -01. Let the quibbling begin ! Klensin Expires April 18, 2005 [Page 3] Internet-Draft ISD Examples October 2004 2. Observations on the Base Document As expected, constructing examples such as there was a learning experience. Even for something as complex as SMTP and its extensions, putting together a skeleton ISD took only a couple of hours. It does require some familiarity with the relevant protocols; it would probaby not be practical for someone without that familiarity to put something together without a lot of work. The classifications, groupings, and comments below are probably controversial but, in some respects, that is exactly the point: if we aren't able to agree on grouping of these things, they should either remain separate or we should be explicit about our disagreements. Of course, as new documents and specifications are developed within the ISD context, authors, editors, and WGs should be expected to make recommendations about grouping. Klensin Expires April 18, 2005 [Page 4] Internet-Draft ISD Examples October 2004 3. Example 1: The Simple Mail Transfer Protocol 3.1 SMTP Comments SMTP was chosen because it is one of the more heavily-used protocols on the Internet and because the notion of a "complete implementation" is both controversial and requires reference to a significant number of documents. The effort, with RFC 2821 [RFC2821], to clean up the multiple-document situation was a success in some respects, but the large number of extensions which that document did not (or could not) address have put us back into a situation as serious as the one we had before the 2821/2822 ("DRUMS") effort started. The relationships of the various documents remains controversial, and the comments below are strictly the opinion of the author. Resolving them for a real ISD document is one of the challenges of the ISD approavh. However, the author's opinion is that either the IETF can reach consensus on those issues or it cannot. Pretending that it can when that is not the case is ultimately not useful; it would be preferable to simply note the lack of consensus and move on, as the example's discussion of the extensions attempts to do. 3.2 ISD xxxx: Simple Mail Transfer Protocol, SMTP Abstract: The Simple Mail Transfer Protocol, more commonly know as just "SMTP", is the Internet's primary standard protocol for the transport of electronic mail between hosts. The long-time standard version was described in RFC 821, which was updated or clarified in several documents. Revisions and extensions during the 1990s updated the original specification with an extension mechanism and a number of clarifications, creating what is sometimes described as "modern" or "contemporary" SMTP. This ISD specifies the SMTP protocol as it is now understood and provides a collection of references to extensions that are not, themselves, part of the standard. 3.2.1 Documents making up the Standard, STD10 RFC2821 Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001. (Status: PROPOSED STANDARD) This is the current base specification for SMTP. Some earlier implementations still legitimately claim conformance only to RFC821, which represents an earlier state of STMP implementations. All implementations that are fully-conformant to RFC 821 and the standards-track documents that qualified, clarified, or updated it, should be compatible with RFC 2821 and this standard, even though they do not support the newer features. RFC 2821 makes RFC0821, RFC0974, and RFC1869 obsolete; those documents are Klensin Expires April 18, 2005 [Page 5] Internet-Draft ISD Examples October 2004 described in the "history" section below (Section 3.2.7). Verified errata: * Section 4.5.5 contains a doubled instance of the word "with". * In Section 3.7, the uses of the word "their" in the sentence "Many historical problems with their interpretation have made their use undesirable." refers to source routes, not MX records. Other putative errata: The RFC Editor has a list of outstanding errata for RFC2821 which, other than those above, are unverified. These can be found by entering the RFC number into the "errata" search page located from http://www.rfc-editor.org/. 3.2.2 Additional Relevant Documents RFC3463 Enhanced Mail System Status Codes. G. Vaudreuil. January 2003. Status: DRAFT STANDARD This document specifies a code system for providing more specificity than the codes specified (and required) by RFC 2821 and the older 821. The codes are used in addition to the classical codes, but do not replace them. Their generation in SMTP server (receiver) implementations is strongly encouraged; SMTP clients can take advantage of them to report additional information to users. Some of the extensions listed below require the use of these codes (see RFC 2034 in particular). The document was updated by RFC3886, which specifies some additional codes. Some of the extensions below also specify additional codes. RFC3848 ESMTP and LMTP Transmission Types Registration. C. Newman. July 2004. Status: PROPOSED STANDARD This document describes additional transmission type codes for use in the Received: header field inserted by SMTP servers. [[Note in draft: Probably a separate ISD with a cross-reference.]] 3.2.3 Extensions to the SMTP Base Specification RFC1652 SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. July 1994. Status: DRAFT STANDARD) This extension is required if 8-bit characters are to be transported, without additional encoding (e.g., with a MIME content-transfer-encoding) in SMTP. It is widely implemented and supported and has been found, for obvious reasons, to be useful. Its "downgrading" options are less widely supported, but become gradually less important as the mechanism is deployed. Klensin Expires April 18, 2005 [Page 6] Internet-Draft ISD Examples October 2004 Posted errata: None RFC1870 SMTP Service Extension for Message Size Declaration. J. Klensin, N. Freed, K. Moore. November 1995. Status: STANDARD) This is a full standard and even more widely supported than the 8-Bit-MIME specification discussed above. Support and implementation are strongly recommended. Posted errata: None RFC2920 SMTP Service Extension for Command Pipelining. N. Freed. September 2000. Status: STANDARD) Posted errata: None [[Note in draft: This is a full standard, currently STD0060. I think it is really an optional to implement, but commonly deployed and recommended, part of SMTP.]] RFC2034 SMTP Service Extension for Returning Enhanced Error Codes. N. Freed. October 1996. Status: PROPOSED STANDARD Provides a specific model for use of enhanced reply codes (see above). RFC2554 SMTP Service Extension for Authentication. J. Myers. March 1999. Status: PROPOSED STANDARD) This is the base "SMTP AUTH" specification, now supported by most clients and servers and required in several environments. [[Note in draft: Something needs to be said about the SASL efforts here, see discussion in Section 4]]. RFC3207 SMTP Service Extension for Secure SMTP over Transport Layer Security. P. Hoffman. February 2002. Status: PROPOSED STANDARD RFC3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages. G. Vaudreuil. December 2000. Status: PROPOSED STANDARD Putative errata: The RFC Editor has a list of outstanding errata for RFC3030 that are unverified. These can be found by entering the RFC number into the "errata" search page located from http://www.rfc-editor.org/. 3.2.4 Related ISDs (temporary) The following documents or document sets should be turned into separate ISDs and then referenced from some sort of "additional Klensin Expires April 18, 2005 [Page 7] Internet-Draft ISD Examples October 2004 references" section here. SMTP Delivery Status Notifications (DSN) The specification of delivery status notifications for email consist of a number of separate documents, and are covered in a separate definition, ISD zzzz. [[Note in draft: or this author got too lazy. RFCs 3461, 3798, 3885, 2852, and probably some others, plus a discussion of the DSN message format, which probably also belongs in the same ISD. The message tracking materials of RFC 3885 and the additional notification format material in RFC 3798 probably belong there too, or in yet another ISD.]] SMTP and SPAM (SMTP-SPAM) There are several different documents covering SMTP-based methods for spam control. These are covered in a separate definition, ISD zyzy. [[Note in draft: or this author got too lazy. RFCs 2505 and 3865 probably belong in separate ISDs since neither depends in any way on the other for implementation.]] On-demand relay, delivery, and alternatives to TURN There are several different documents covering methods by which a client machine, or a third party, can start delivery of a message queue from an SMTP server. These are covered in a separate definition, ISD yzyz. [[Note in draft: or this author got too lazy. RFCs 1985 and 2645 probably belong in separate ISDs since neither depends in any way on the other for implementation.]] 3.2.5 Experimental Extensions These extensions are included for reference and information only. The IETF has not concluded that they are ready for standards-track treatment and deficiencies may be known but not documented formally. RFC1830 SMTP Service Extensions for Transmission of Large and Binary MIME Messages. G. Vaudreuil. August 1995. (Obsoleted by RFC3030) Status: EXPERIMENTAL) RFC1845 SMTP Service Extension for Checkpoint/Restart. D. Crocker, N. Freed, A. Cargille. September 1995. Status: EXPERIMENTAL) 3.2.6 Comments on Related Documents This section discusses some documents that preceed the first ISD publication of a document describing this standard, so dates are not given. Klensin Expires April 18, 2005 [Page 8] Internet-Draft ISD Examples October 2004 RFC0821 Simple Mail Transfer Protocol. J. Postel. Aug-01-1982. (Obsoletes RFC0788) (Obsoleted by RFC2821) (Also STD0010). Superceded in practice by RFC 2821, as described above. RFC0974 Mail routing and the domain system. C. Partridge. Jan-01-1986. This document was incorporated into SMTP and made mandatory by RFC 1123. Its substance has been incorporated into RFC 2821 and the document itself classified as historic. RFC1869 SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. November 1995. (Status: STANDARD). This document and its predecessors defined the extension mechanism for SMTP and imposed the requirement that fully-conforming SMTP implementations support those mechanisms. All of its functional capabilities were incorporated into RFC 2821. RFC1047 Duplicate messages and SMTP. C. Partridge. Feb-01-1988. (Status: UNKNOWN) The substance of this document is believed to have been incorporated into RFC 2821. RFC1090 SMTP on X.25. R. Ullmann. Feb-01-1989. (Status: UNKNOWN) This protocol is generally considered obsolete. X.25 itself is falling into disuse and most use of SMTP in X.25 environments involves a TCP/IP transport over X.25, then running SMTP normally over TCP. [[Note in draft to Cruft Committee (see [NewtrkHistoric]), if any: this one is low-hanging fruit.]] RFC1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME. G. Vaudreuil. February 1993. Status: INFORMATIONAL This document provided important transitional information but, a decade later, the transitional problem appears to have been largely solved and the consenus among most SMTP implementors and implementations is that "just send 8" implementions are broken. RFC1846 SMTP 521 Reply Code. A. Durand, F. Dupont. September 1995. Status: EXPERIMENTAL The IETF, in the process of constructing RFC 2821, reviewed this model and proposal and decided to not incorporate exactly what it proposed. RFC 2821 is authoritative on the 521 reply code. Klensin Expires April 18, 2005 [Page 9] Internet-Draft ISD Examples October 2004 3.2.7 History and Tracking Information ...To be supplied... [[Note in draft: A discussion of just what belongs here, e.g., dates and the nature of the change, or complete previous information of documents that have been removed/obsoleted as Scott's "standards process" document does, would be helpful.]] Klensin Expires April 18, 2005 [Page 10] Internet-Draft ISD Examples October 2004 4. Example 2: POP/IMAP Authentication with CRAM-MD5 4.1 POP/AUTH CRAM-MD5 Comments This one ought to be a simple case, since it is associated with only a single current document (and one that it quickly rendered obsolete), but it raises some interesting issues. One is how to construct a name/acronym, since this is most commonly known by names that don't appear in the title of the RFC. Another is what, if anything to say about the effort to supercede this with a SASL mechanism: when that is done, the ISD document will be an appropriate place to note and describe the relationship but, until then... 4.2 ISD yyyy: POP/IMAP Authentication with CRAM-MD5, CRAM-MD5 Abstract: While IMAP4 supports a number of strong authentication mechanisms as described in RFC 1731, it lacks any mechanism that neither passes cleartext, reusable passwords across the network nor requires either a significant security infrastructure or that the mail server update a mail-system-wide user authentication file on each mail access. This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. Since it utilizes Keyed-MD5 digests and does not require that the secret be stored in the clear on the server, it may also constitute an improvement on APOP for POP3 use as specified in RFC 1734. RFC Reference: RFC 2195 IMAP/POP AUTHorize Extension for Simple Challenge/Response. J. Klensin, R. Catoe, P. Krumviede. September 1997. Status: PROPOSED STANDARD This protocol is widely supported in both clients and servers and is required by a number of major ISPs. Klensin Expires April 18, 2005 [Page 11] Internet-Draft ISD Examples October 2004 5. Security Considerations and Other Boilerplate As discusssed in [ISD-definition], security considerations and similar material may not be appropriate for ISDs, or may apply to individual components that make up the ISD rather than the standard in total. See that document for further discussion. Klensin Expires April 18, 2005 [Page 12] Internet-Draft ISD Examples October 2004 6. References 6.1 Normative References [ISD-definition] Klensin, J. and J. Loughney, "Internet Standards Documentation (ISDs)", draft-ietf-newtrk-repurposing-isd-00 (work in progress), September 2004. [RFC2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. 6.2 Informative References [NewtrkHistoric] Alvestrand, H. and E. Lear, "Getting rid of the cruft: A procedure to deprecate old standards", draft-ietf-newtrk-cruft-00 (work in progress), October 2004. Author's Address John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 EMail: john-ietf@jck.com Klensin Expires April 18, 2005 [Page 13] Internet-Draft ISD Examples October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Klensin Expires April 18, 2005 [Page 14] Network Working Group J. Klensin Internet-Draft October 18, 2004 Expires: April 18, 2005 Internet Standards Documentation (ISDs) - Examples draft-klensin-newtrk-sample-isd-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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 April 18, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract The proposal to define what is actually an IETF standard and to create ways of explaining and qualifying its applicability and relationship to other documents has been described in an Internet-Draft, "Internet Standards Documentation (ISDs)" (draft-ietf-newtrk-repurposing-isd-00). This document provides some examples of what such documents might look like. It includes a very complicated example (SMTP) and a fairly simple one (the IMAP/POP authorization specification of RFC 2195, which has not progressed Klensin Expires April 18, 2005 [Page 1] Internet-Draft ISD Examples October 2004 beyond Proposed Standard). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Observations on the Base Document . . . . . . . . . . . . . . 4 3. Example 1: The Simple Mail Transfer Protocol . . . . . . . . . 5 3.1 SMTP Comments . . . . . . . . . . . . . . . . . . . . . . 5 3.2 ISD xxxx: Simple Mail Transfer Protocol, SMTP . . . . . . 5 3.2.1 Documents making up the Standard, STD10 . . . . . . . 5 3.2.2 Additional Relevant Documents . . . . . . . . . . . . 6 3.2.3 Extensions to the SMTP Base Specification . . . . . . 6 3.2.4 Related ISDs (temporary) . . . . . . . . . . . . . . . 7 3.2.5 Experimental Extensions . . . . . . . . . . . . . . . 8 3.2.6 Comments on Related Documents . . . . . . . . . . . . 8 3.2.7 History and Tracking Information . . . . . . . . . . . 10 4. Example 2: POP/IMAP Authentication with CRAM-MD5 . . . . . . . 11 4.1 POP/AUTH CRAM-MD5 Comments . . . . . . . . . . . . . . . . 11 4.2 ISD yyyy: POP/IMAP Authentication with CRAM-MD5, CRAM-MD5 . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations and Other Boilerplate . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 6.2 Informative References . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Klensin Expires April 18, 2005 [Page 2] Internet-Draft ISD Examples October 2004 1. Introduction The proposal to define what is actually an IETF standard and to create ways of explaining and qualifying its applicability and relationship to other documents has been described in an Internet-Draft, "Internet Standards Documentation (ISDs)" [ISD-definition]. This document provides some examples of what such documents might look like. It includes a very complicated example (SMTP) and a fairly simple one (the IMAP/POP authorization specification of RFC 2195 [RFC2195], which has not progressed beyond Proposed Standard). It is worth stressing that little effort has been made to check most of the statements in the examples for accuracy; they were constructed from the author's (failing) memory only. If a successor to the ISD proposal document is ultimately approved, the examples here should evolve into actual ISD documents; this document itself is not expected to evolve into an RFC of any type. Due to some issues with tools (or the author's lack of familiarity with them), no attempt has been made to get the formating of the sample documents correct in this draft. I prefer the format used in Scott Bradner's treatment of the standards process document. What is here should be enough to stimulate a discussion of content; perhaps the format can be upgraded at -01. Let the quibbling begin ! Klensin Expires April 18, 2005 [Page 3] Internet-Draft ISD Examples October 2004 2. Observations on the Base Document As expected, constructing examples such as there was a learning experience. Even for something as complex as SMTP and its extensions, putting together a skeleton ISD took only a couple of hours. It does require some familiarity with the relevant protocols; it would probaby not be practical for someone without that familiarity to put something together without a lot of work. The classifications, groupings, and comments below are probably controversial but, in some respects, that is exactly the point: if we aren't able to agree on grouping of these things, they should either remain separate or we should be explicit about our disagreements. Of course, as new documents and specifications are developed within the ISD context, authors, editors, and WGs should be expected to make recommendations about grouping. Klensin Expires April 18, 2005 [Page 4] Internet-Draft ISD Examples October 2004 3. Example 1: The Simple Mail Transfer Protocol 3.1 SMTP Comments SMTP was chosen because it is one of the more heavily-used protocols on the Internet and because the notion of a "complete implementation" is both controversial and requires reference to a significant number of documents. The effort, with RFC 2821 [RFC2821], to clean up the multiple-document situation was a success in some respects, but the large number of extensions which that document did not (or could not) address have put us back into a situation as serious as the one we had before the 2821/2822 ("DRUMS") effort started. The relationships of the various documents remains controversial, and the comments below are strictly the opinion of the author. Resolving them for a real ISD document is one of the challenges of the ISD approavh. However, the author's opinion is that either the IETF can reach consensus on those issues or it cannot. Pretending that it can when that is not the case is ultimately not useful; it would be preferable to simply note the lack of consensus and move on, as the example's discussion of the extensions attempts to do. 3.2 ISD xxxx: Simple Mail Transfer Protocol, SMTP Abstract: The Simple Mail Transfer Protocol, more commonly know as just "SMTP", is the Internet's primary standard protocol for the transport of electronic mail between hosts. The long-time standard version was described in RFC 821, which was updated or clarified in several documents. Revisions and extensions during the 1990s updated the original specification with an extension mechanism and a number of clarifications, creating what is sometimes described as "modern" or "contemporary" SMTP. This ISD specifies the SMTP protocol as it is now understood and provides a collection of references to extensions that are not, themselves, part of the standard. 3.2.1 Documents making up the Standard, STD10 RFC2821 Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001. (Status: PROPOSED STANDARD) This is the current base specification for SMTP. Some earlier implementations still legitimately claim conformance only to RFC821, which represents an earlier state of STMP implementations. All implementations that are fully-conformant to RFC 821 and the standards-track documents that qualified, clarified, or updated it, should be compatible with RFC 2821 and this standard, even though they do not support the newer features. RFC 2821 makes RFC0821, RFC0974, and RFC1869 obsolete; those documents are Klensin Expires April 18, 2005 [Page 5] Internet-Draft ISD Examples October 2004 described in the "history" section below (Section 3.2.7). Verified errata: * Section 4.5.5 contains a doubled instance of the word "with". * In Section 3.7, the uses of the word "their" in the sentence "Many historical problems with their interpretation have made their use undesirable." refers to source routes, not MX records. Other putative errata: The RFC Editor has a list of outstanding errata for RFC2821 which, other than those above, are unverified. These can be found by entering the RFC number into the "errata" search page located from http://www.rfc-editor.org/. 3.2.2 Additional Relevant Documents RFC3463 Enhanced Mail System Status Codes. G. Vaudreuil. January 2003. Status: DRAFT STANDARD This document specifies a code system for providing more specificity than the codes specified (and required) by RFC 2821 and the older 821. The codes are used in addition to the classical codes, but do not replace them. Their generation in SMTP server (receiver) implementations is strongly encouraged; SMTP clients can take advantage of them to report additional information to users. Some of the extensions listed below require the use of these codes (see RFC 2034 in particular). The document was updated by RFC3886, which specifies some additional codes. Some of the extensions below also specify additional codes. RFC3848 ESMTP and LMTP Transmission Types Registration. C. Newman. July 2004. Status: PROPOSED STANDARD This document describes additional transmission type codes for use in the Received: header field inserted by SMTP servers. [[Note in draft: Probably a separate ISD with a cross-reference.]] 3.2.3 Extensions to the SMTP Base Specification RFC1652 SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. July 1994. Status: DRAFT STANDARD) This extension is required if 8-bit characters are to be transported, without additional encoding (e.g., with a MIME content-transfer-encoding) in SMTP. It is widely implemented and supported and has been found, for obvious reasons, to be useful. Its "downgrading" options are less widely supported, but become gradually less important as the mechanism is deployed. Klensin Expires April 18, 2005 [Page 6] Internet-Draft ISD Examples October 2004 Posted errata: None RFC1870 SMTP Service Extension for Message Size Declaration. J. Klensin, N. Freed, K. Moore. November 1995. Status: STANDARD) This is a full standard and even more widely supported than the 8-Bit-MIME specification discussed above. Support and implementation are strongly recommended. Posted errata: None RFC2920 SMTP Service Extension for Command Pipelining. N. Freed. September 2000. Status: STANDARD) Posted errata: None [[Note in draft: This is a full standard, currently STD0060. I think it is really an optional to implement, but commonly deployed and recommended, part of SMTP.]] RFC2034 SMTP Service Extension for Returning Enhanced Error Codes. N. Freed. October 1996. Status: PROPOSED STANDARD Provides a specific model for use of enhanced reply codes (see above). RFC2554 SMTP Service Extension for Authentication. J. Myers. March 1999. Status: PROPOSED STANDARD) This is the base "SMTP AUTH" specification, now supported by most clients and servers and required in several environments. [[Note in draft: Something needs to be said about the SASL efforts here, see discussion in Section 4]]. RFC3207 SMTP Service Extension for Secure SMTP over Transport Layer Security. P. Hoffman. February 2002. Status: PROPOSED STANDARD RFC3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages. G. Vaudreuil. December 2000. Status: PROPOSED STANDARD Putative errata: The RFC Editor has a list of outstanding errata for RFC3030 that are unverified. These can be found by entering the RFC number into the "errata" search page located from http://www.rfc-editor.org/. 3.2.4 Related ISDs (temporary) The following documents or document sets should be turned into separate ISDs and then referenced from some sort of "additional Klensin Expires April 18, 2005 [Page 7] Internet-Draft ISD Examples October 2004 references" section here. SMTP Delivery Status Notifications (DSN) The specification of delivery status notifications for email consist of a number of separate documents, and are covered in a separate definition, ISD zzzz. [[Note in draft: or this author got too lazy. RFCs 3461, 3798, 3885, 2852, and probably some others, plus a discussion of the DSN message format, which probably also belongs in the same ISD. The message tracking materials of RFC 3885 and the additional notification format material in RFC 3798 probably belong there too, or in yet another ISD.]] SMTP and SPAM (SMTP-SPAM) There are several different documents covering SMTP-based methods for spam control. These are covered in a separate definition, ISD zyzy. [[Note in draft: or this author got too lazy. RFCs 2505 and 3865 probably belong in separate ISDs since neither depends in any way on the other for implementation.]] On-demand relay, delivery, and alternatives to TURN There are several different documents covering methods by which a client machine, or a third party, can start delivery of a message queue from an SMTP server. These are covered in a separate definition, ISD yzyz. [[Note in draft: or this author got too lazy. RFCs 1985 and 2645 probably belong in separate ISDs since neither depends in any way on the other for implementation.]] 3.2.5 Experimental Extensions These extensions are included for reference and information only. The IETF has not concluded that they are ready for standards-track treatment and deficiencies may be known but not documented formally. RFC1830 SMTP Service Extensions for Transmission of Large and Binary MIME Messages. G. Vaudreuil. August 1995. (Obsoleted by RFC3030) Status: EXPERIMENTAL) RFC1845 SMTP Service Extension for Checkpoint/Restart. D. Crocker, N. Freed, A. Cargille. September 1995. Status: EXPERIMENTAL) 3.2.6 Comments on Related Documents This section discusses some documents that preceed the first ISD publication of a document describing this standard, so dates are not given. Klensin Expires April 18, 2005 [Page 8] Internet-Draft ISD Examples October 2004 RFC0821 Simple Mail Transfer Protocol. J. Postel. Aug-01-1982. (Obsoletes RFC0788) (Obsoleted by RFC2821) (Also STD0010). Superceded in practice by RFC 2821, as described above. RFC0974 Mail routing and the domain system. C. Partridge. Jan-01-1986. This document was incorporated into SMTP and made mandatory by RFC 1123. Its substance has been incorporated into RFC 2821 and the document itself classified as historic. RFC1869 SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. November 1995. (Status: STANDARD). This document and its predecessors defined the extension mechanism for SMTP and imposed the requirement that fully-conforming SMTP implementations support those mechanisms. All of its functional capabilities were incorporated into RFC 2821. RFC1047 Duplicate messages and SMTP. C. Partridge. Feb-01-1988. (Status: UNKNOWN) The substance of this document is believed to have been incorporated into RFC 2821. RFC1090 SMTP on X.25. R. Ullmann. Feb-01-1989. (Status: UNKNOWN) This protocol is generally considered obsolete. X.25 itself is falling into disuse and most use of SMTP in X.25 environments involves a TCP/IP transport over X.25, then running SMTP normally over TCP. [[Note in draft to Cruft Committee (see [NewtrkHistoric]), if any: this one is low-hanging fruit.]] RFC1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME. G. Vaudreuil. February 1993. Status: INFORMATIONAL This document provided important transitional information but, a decade later, the transitional problem appears to have been largely solved and the consenus among most SMTP implementors and implementations is that "just send 8" implementions are broken. RFC1846 SMTP 521 Reply Code. A. Durand, F. Dupont. September 1995. Status: EXPERIMENTAL The IETF, in the process of constructing RFC 2821, reviewed this model and proposal and decided to not incorporate exactly what it proposed. RFC 2821 is authoritative on the 521 reply code. Klensin Expires April 18, 2005 [Page 9] Internet-Draft ISD Examples October 2004 3.2.7 History and Tracking Information ...To be supplied... [[Note in draft: A discussion of just what belongs here, e.g., dates and the nature of the change, or complete previous information of documents that have been removed/obsoleted as Scott's "standards process" document does, would be helpful.]] Klensin Expires April 18, 2005 [Page 10] Internet-Draft ISD Examples October 2004 4. Example 2: POP/IMAP Authentication with CRAM-MD5 4.1 POP/AUTH CRAM-MD5 Comments This one ought to be a simple case, since it is associated with only a single current document (and one that it quickly rendered obsolete), but it raises some interesting issues. One is how to construct a name/acronym, since this is most commonly known by names that don't appear in the title of the RFC. Another is what, if anything to say about the effort to supercede this with a SASL mechanism: when that is done, the ISD document will be an appropriate place to note and describe the relationship but, until then... 4.2 ISD yyyy: POP/IMAP Authentication with CRAM-MD5, CRAM-MD5 Abstract: While IMAP4 supports a number of strong authentication mechanisms as described in RFC 1731, it lacks any mechanism that neither passes cleartext, reusable passwords across the network nor requires either a significant security infrastructure or that the mail server update a mail-system-wide user authentication file on each mail access. This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. Since it utilizes Keyed-MD5 digests and does not require that the secret be stored in the clear on the server, it may also constitute an improvement on APOP for POP3 use as specified in RFC 1734. RFC Reference: RFC 2195 IMAP/POP AUTHorize Extension for Simple Challenge/Response. J. Klensin, R. Catoe, P. Krumviede. September 1997. Status: PROPOSED STANDARD This protocol is widely supported in both clients and servers and is required by a number of major ISPs. Klensin Expires April 18, 2005 [Page 11] Internet-Draft ISD Examples October 2004 5. Security Considerations and Other Boilerplate As discusssed in [ISD-definition], security considerations and similar material may not be appropriate for ISDs, or may apply to individual components that make up the ISD rather than the standard in total. See that document for further discussion. Klensin Expires April 18, 2005 [Page 12] Internet-Draft ISD Examples October 2004 6. References 6.1 Normative References [ISD-definition] Klensin, J. and J. Loughney, "Internet Standards Documentation (ISDs)", draft-ietf-newtrk-repurposing-isd-00 (work in progress), September 2004. [RFC2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. 6.2 Informative References [NewtrkHistoric] Alvestrand, H. and E. Lear, "Getting rid of the cruft: A procedure to deprecate old standards", draft-ietf-newtrk-cruft-00 (work in progress), October 2004. Author's Address John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 EMail: john-ietf@jck.com Klensin Expires April 18, 2005 [Page 13] Internet-Draft ISD Examples October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Klensin Expires April 18, 2005 [Page 14]