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]
