[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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]