idnits 2.17.1 draft-ietf-newtrk-sample-isd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 508. -- Found old boilerplate from RFC 3978, Section 5.5 on line 974. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 951. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 958. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 964. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 277 has weird spacing: '...robably belon...' == Line 770 has weird spacing: '...robably belon...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 2004) is 7130 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-ietf-newtrk-repurposing-isd-00 -- Possible downref: Normative reference to a draft: ref. 'ISD-definition' ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Klensin 2 Internet-Draft October 18, 2004 3 Expires: April 18, 2005 5 Internet Standards Documentation (ISDs) - Examples 6 draft-ietf-newtrk-sample-isd-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 18, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). 39 Abstract 41 The proposal to define what is actually an IETF standard and to 42 create ways of explaining and qualifying its applicability and 43 relationship to other documents has been described in an 44 Internet-Draft, "Internet Standards Documentation (ISDs)" 45 (draft-ietf-newtrk-repurposing-isd-00). This document provides some 46 examples of what such documents might look like. It includes a very 47 complicated example (SMTP) and a fairly simple one (the IMAP/POP 48 authorization specification of RFC 2195, which has not progressed 49 beyond Proposed Standard). 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Observations on the Base Document . . . . . . . . . . . . . . 4 55 3. Example 1: The Simple Mail Transfer Protocol . . . . . . . . . 5 56 3.1 SMTP Comments . . . . . . . . . . . . . . . . . . . . . . 5 57 3.2 ISD xxxx: Simple Mail Transfer Protocol, SMTP . . . . . . 5 58 3.2.1 Documents making up the Standard, STD10 . . . . . . . 5 59 3.2.2 Additional Relevant Documents . . . . . . . . . . . . 6 60 3.2.3 Extensions to the SMTP Base Specification . . . . . . 6 61 3.2.4 Related ISDs (temporary) . . . . . . . . . . . . . . . 7 62 3.2.5 Experimental Extensions . . . . . . . . . . . . . . . 8 63 3.2.6 Comments on Related Documents . . . . . . . . . . . . 8 64 3.2.7 History and Tracking Information . . . . . . . . . . . 10 65 4. Example 2: POP/IMAP Authentication with CRAM-MD5 . . . . . . . 11 66 4.1 POP/AUTH CRAM-MD5 Comments . . . . . . . . . . . . . . . . 11 67 4.2 ISD yyyy: POP/IMAP Authentication with CRAM-MD5, 68 CRAM-MD5 . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 5. Security Considerations and Other Boilerplate . . . . . . . . 12 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 72 6.2 Informative References . . . . . . . . . . . . . . . . . . . 13 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 74 Intellectual Property and Copyright Statements . . . . . . . . 14 76 1. Introduction 78 The proposal to define what is actually an IETF standard and to 79 create ways of explaining and qualifying its applicability and 80 relationship to other documents has been described in an 81 Internet-Draft, "Internet Standards Documentation (ISDs)" 82 [ISD-definition]. This document provides some examples of what such 83 documents might look like. It includes a very complicated example 84 (SMTP) and a fairly simple one (the IMAP/POP authorization 85 specification of RFC 2195 [RFC2195], which has not progressed beyond 86 Proposed Standard). 88 It is worth stressing that little effort has been made to check most 89 of the statements in the examples for accuracy; they were constructed 90 from the author's (failing) memory only. 92 If a successor to the ISD proposal document is ultimately approved, 93 the examples here should evolve into actual ISD documents; this 94 document itself is not expected to evolve into an RFC of any type. 96 Due to some issues with tools (or the author's lack of familiarity 97 with them), no attempt has been made to get the formating of the 98 sample documents correct in this draft. I prefer the format used in 99 Scott Bradner's treatment of the standards process document. What is 100 here should be enough to stimulate a discussion of content; perhaps 101 the format can be upgraded at -01. 103 Let the quibbling begin ! 105 2. Observations on the Base Document 107 As expected, constructing examples such as there was a learning 108 experience. Even for something as complex as SMTP and its 109 extensions, putting together a skeleton ISD took only a couple of 110 hours. It does require some familiarity with the relevant protocols; 111 it would probaby not be practical for someone without that 112 familiarity to put something together without a lot of work. 114 The classifications, groupings, and comments below are probably 115 controversial but, in some respects, that is exactly the point: if we 116 aren't able to agree on grouping of these things, they should either 117 remain separate or we should be explicit about our disagreements. Of 118 course, as new documents and specifications are developed within the 119 ISD context, authors, editors, and WGs should be expected to make 120 recommendations about grouping. 122 3. Example 1: The Simple Mail Transfer Protocol 124 3.1 SMTP Comments 126 SMTP was chosen because it is one of the more heavily-used protocols 127 on the Internet and because the notion of a "complete implementation" 128 is both controversial and requires reference to a significant number 129 of documents. The effort, with RFC 2821 [RFC2821], to clean up the 130 multiple-document situation was a success in some respects, but the 131 large number of extensions which that document did not (or could not) 132 address have put us back into a situation as serious as the one we 133 had before the 2821/2822 ("DRUMS") effort started. 135 The relationships of the various documents remains controversial, and 136 the comments below are strictly the opinion of the author. Resolving 137 them for a real ISD document is one of the challenges of the ISD 138 approavh. However, the author's opinion is that either the IETF can 139 reach consensus on those issues or it cannot. Pretending that it can 140 when that is not the case is ultimately not useful; it would be 141 preferable to simply note the lack of consensus and move on, as the 142 example's discussion of the extensions attempts to do. 144 3.2 ISD xxxx: Simple Mail Transfer Protocol, SMTP 146 Abstract: The Simple Mail Transfer Protocol, more commonly know as 147 just "SMTP", is the Internet's primary standard protocol for the 148 transport of electronic mail between hosts. The long-time standard 149 version was described in RFC 821, which was updated or clarified in 150 several documents. Revisions and extensions during the 1990s updated 151 the original specification with an extension mechanism and a number 152 of clarifications, creating what is sometimes described as "modern" 153 or "contemporary" SMTP. This ISD specifies the SMTP protocol as it 154 is now understood and provides a collection of references to 155 extensions that are not, themselves, part of the standard. 157 3.2.1 Documents making up the Standard, STD10 159 RFC2821 160 Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001. 161 (Status: PROPOSED STANDARD) 162 This is the current base specification for SMTP. Some earlier 163 implementations still legitimately claim conformance only to 164 RFC821, which represents an earlier state of STMP implementations. 165 All implementations that are fully-conformant to RFC 821 and the 166 standards-track documents that qualified, clarified, or updated 167 it, should be compatible with RFC 2821 and this standard, even 168 though they do not support the newer features. RFC 2821 makes 169 RFC0821, RFC0974, and RFC1869 obsolete; those documents are 170 described in the "history" section below (Section 3.2.7). 171 Verified errata: 172 * Section 4.5.5 contains a doubled instance of the word "with". 173 * In Section 3.7, the uses of the word "their" in the sentence 174 "Many historical problems with their interpretation have made 175 their use undesirable." refers to source routes, not MX 176 records. 177 Other putative errata: The RFC Editor has a list of outstanding 178 errata for RFC2821 which, other than those above, are unverified. 179 These can be found by entering the RFC number into the "errata" 180 search page located from http://www.rfc-editor.org/. 182 3.2.2 Additional Relevant Documents 184 RFC3463 185 Enhanced Mail System Status Codes. G. Vaudreuil. January 2003. 186 Status: DRAFT STANDARD 187 This document specifies a code system for providing more 188 specificity than the codes specified (and required) by RFC 2821 189 and the older 821. The codes are used in addition to the 190 classical codes, but do not replace them. Their generation in 191 SMTP server (receiver) implementations is strongly encouraged; 192 SMTP clients can take advantage of them to report additional 193 information to users. Some of the extensions listed below require 194 the use of these codes (see RFC 2034 in particular). 195 The document was updated by RFC3886, which specifies some 196 additional codes. Some of the extensions below also specify 197 additional codes. 198 RFC3848 199 ESMTP and LMTP Transmission Types Registration. C. Newman. July 200 2004. 201 Status: PROPOSED STANDARD 202 This document describes additional transmission type codes for use 203 in the Received: header field inserted by SMTP servers. 204 [[Note in draft: Probably a separate ISD with a cross-reference.]] 206 3.2.3 Extensions to the SMTP Base Specification 208 RFC1652 209 SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N. 210 Freed, M. Rose, E. Stefferud, D. Crocker. July 1994. 211 Status: DRAFT STANDARD) 212 This extension is required if 8-bit characters are to be 213 transported, without additional encoding (e.g., with a MIME 214 content-transfer-encoding) in SMTP. It is widely implemented and 215 supported and has been found, for obvious reasons, to be useful. 216 Its "downgrading" options are less widely supported, but become 217 gradually less important as the mechanism is deployed. 219 Posted errata: None 220 RFC1870 221 SMTP Service Extension for Message Size Declaration. J. Klensin, 222 N. Freed, K. Moore. November 1995. 223 Status: STANDARD) 224 This is a full standard and even more widely supported than the 225 8-Bit-MIME specification discussed above. Support and 226 implementation are strongly recommended. 227 Posted errata: None 228 RFC2920 229 SMTP Service Extension for Command Pipelining. N. Freed. 230 September 2000. 231 Status: STANDARD) 232 Posted errata: None 233 [[Note in draft: This is a full standard, currently STD0060. I 234 think it is really an optional to implement, but commonly deployed 235 and recommended, part of SMTP.]] 236 RFC2034 237 SMTP Service Extension for Returning Enhanced Error Codes. N. 238 Freed. October 1996. 239 Status: PROPOSED STANDARD 240 Provides a specific model for use of enhanced reply codes (see 241 above). 242 RFC2554 243 SMTP Service Extension for Authentication. J. Myers. March 244 1999. 245 Status: PROPOSED STANDARD) 246 This is the base "SMTP AUTH" specification, now supported by most 247 clients and servers and required in several environments. 248 [[Note in draft: Something needs to be said about the SASL efforts 249 here, see discussion in Section 4]]. 250 RFC3207 251 SMTP Service Extension for Secure SMTP over Transport Layer 252 Security. P. Hoffman. February 2002. 253 Status: PROPOSED STANDARD 254 RFC3030 255 SMTP Service Extensions for Transmission of Large and Binary MIME 256 Messages. G. Vaudreuil. December 2000. 257 Status: PROPOSED STANDARD 258 Putative errata: The RFC Editor has a list of outstanding errata 259 for RFC3030 that are unverified. These can be found by entering 260 the RFC number into the "errata" search page located from 261 http://www.rfc-editor.org/. 263 3.2.4 Related ISDs (temporary) 265 The following documents or document sets should be turned into 266 separate ISDs and then referenced from some sort of "additional 267 references" section here. 269 SMTP Delivery Status Notifications (DSN) 270 The specification of delivery status notifications for email 271 consist of a number of separate documents, and are covered in a 272 separate definition, ISD zzzz. 273 [[Note in draft: or this author got too lazy. RFCs 3461, 3798, 274 3885, 2852, and probably some others, plus a discussion of the DSN 275 message format, which probably also belongs in the same ISD. The 276 message tracking materials of RFC 3885 and the additional 277 notification format material in RFC 3798 probably belong there 278 too, or in yet another ISD.]] 279 SMTP and SPAM (SMTP-SPAM) 280 There are several different documents covering SMTP-based methods 281 for spam control. These are covered in a separate definition, ISD 282 zyzy. 283 [[Note in draft: or this author got too lazy. RFCs 2505 and 3865 284 probably belong in separate ISDs since neither depends in any way 285 on the other for implementation.]] 286 On-demand relay, delivery, and alternatives to TURN 287 There are several different documents covering methods by which a 288 client machine, or a third party, can start delivery of a message 289 queue from an SMTP server. These are covered in a separate 290 definition, ISD yzyz. 291 [[Note in draft: or this author got too lazy. RFCs 1985 and 2645 292 probably belong in separate ISDs since neither depends in any way 293 on the other for implementation.]] 295 3.2.5 Experimental Extensions 297 These extensions are included for reference and information only. 298 The IETF has not concluded that they are ready for standards-track 299 treatment and deficiencies may be known but not documented formally. 301 RFC1830 302 SMTP Service Extensions for Transmission of Large and Binary MIME 303 Messages. G. Vaudreuil. August 1995. (Obsoleted by RFC3030) 304 Status: EXPERIMENTAL) 305 RFC1845 306 SMTP Service Extension for Checkpoint/Restart. D. Crocker, N. 307 Freed, A. Cargille. September 1995. 308 Status: EXPERIMENTAL) 310 3.2.6 Comments on Related Documents 312 This section discusses some documents that preceed the first ISD 313 publication of a document describing this standard, so dates are not 314 given. 316 RFC0821 317 Simple Mail Transfer Protocol. J. Postel. Aug-01-1982. 318 (Obsoletes RFC0788) (Obsoleted by RFC2821) (Also STD0010). 319 Superceded in practice by RFC 2821, as described above. 320 RFC0974 321 Mail routing and the domain system. C. Partridge. Jan-01-1986. 322 This document was incorporated into SMTP and made mandatory by RFC 323 1123. Its substance has been incorporated into RFC 2821 and the 324 document itself classified as historic. 325 RFC1869 326 SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E. 327 Stefferud, D. Crocker. November 1995. 328 (Status: STANDARD). 329 This document and its predecessors defined the extension mechanism 330 for SMTP and imposed the requirement that fully-conforming SMTP 331 implementations support those mechanisms. All of its functional 332 capabilities were incorporated into RFC 2821. 333 RFC1047 334 Duplicate messages and SMTP. C. Partridge. Feb-01-1988. 335 (Status: UNKNOWN) 336 The substance of this document is believed to have been 337 incorporated into RFC 2821. 338 RFC1090 339 SMTP on X.25. R. Ullmann. Feb-01-1989. 340 (Status: UNKNOWN) 341 This protocol is generally considered obsolete. X.25 itself is 342 falling into disuse and most use of SMTP in X.25 environments 343 involves a TCP/IP transport over X.25, then running SMTP normally 344 over TCP. 345 [[Note in draft to Cruft Committee (see [NewtrkHistoric]), if any: 346 this one is low-hanging fruit.]] 347 RFC1428 348 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME. 349 G. Vaudreuil. February 1993. 350 Status: INFORMATIONAL 351 This document provided important transitional information but, a 352 decade later, the transitional problem appears to have been 353 largely solved and the consenus among most SMTP implementors and 354 implementations is that "just send 8" implementions are broken. 355 RFC1846 356 SMTP 521 Reply Code. A. Durand, F. Dupont. September 1995. 357 Status: EXPERIMENTAL 358 The IETF, in the process of constructing RFC 2821, reviewed this 359 model and proposal and decided to not incorporate exactly what it 360 proposed. RFC 2821 is authoritative on the 521 reply code. 362 3.2.7 History and Tracking Information 364 ...To be supplied... 366 [[Note in draft: A discussion of just what belongs here, e.g., dates 367 and the nature of the change, or complete previous information of 368 documents that have been removed/obsoleted as Scott's "standards 369 process" document does, would be helpful.]] 371 4. Example 2: POP/IMAP Authentication with CRAM-MD5 373 4.1 POP/AUTH CRAM-MD5 Comments 375 This one ought to be a simple case, since it is associated with only 376 a single current document (and one that it quickly rendered 377 obsolete), but it raises some interesting issues. One is how to 378 construct a name/acronym, since this is most commonly known by names 379 that don't appear in the title of the RFC. Another is what, if 380 anything to say about the effort to supercede this with a SASL 381 mechanism: when that is done, the ISD document will be an appropriate 382 place to note and describe the relationship but, until then... 384 4.2 ISD yyyy: POP/IMAP Authentication with CRAM-MD5, CRAM-MD5 386 Abstract: While IMAP4 supports a number of strong authentication 387 mechanisms as described in RFC 1731, it lacks any mechanism that 388 neither passes cleartext, reusable passwords across the network nor 389 requires either a significant security infrastructure or that the 390 mail server update a mail-system-wide user authentication file on 391 each mail access. This specification provides a simple 392 challenge-response authentication protocol that is suitable for use 393 with IMAP4. Since it utilizes Keyed-MD5 digests and does not require 394 that the secret be stored in the clear on the server, it may also 395 constitute an improvement on APOP for POP3 use as specified in RFC 396 1734. 398 RFC Reference: RFC 2195 IMAP/POP AUTHorize Extension for Simple 399 Challenge/Response. J. Klensin, R. Catoe, P. Krumviede. 400 September 1997. 402 Status: PROPOSED STANDARD 404 This protocol is widely supported in both clients and servers and is 405 required by a number of major ISPs. 407 5. Security Considerations and Other Boilerplate 409 As discusssed in [ISD-definition], security considerations and 410 similar material may not be appropriate for ISDs, or may apply to 411 individual components that make up the ISD rather than the standard 412 in total. See that document for further discussion. 414 6. References 416 6.1 Normative References 418 [ISD-definition] 419 Klensin, J. and J. Loughney, "Internet Standards 420 Documentation (ISDs)", 421 draft-ietf-newtrk-repurposing-isd-00 (work in progress), 422 September 2004. 424 [RFC2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP 425 AUTHorize Extension for Simple Challenge/Response", RFC 426 2195, September 1997. 428 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 429 April 2001. 431 6.2 Informative References 433 [NewtrkHistoric] 434 Alvestrand, H. and E. Lear, "Getting rid of the cruft: A 435 procedure to deprecate old standards", 436 draft-ietf-newtrk-cruft-00 (work in progress), October 437 2004. 439 Author's Address 441 John C Klensin 442 1770 Massachusetts Ave, #322 443 Cambridge, MA 02140 444 USA 446 Phone: +1 617 491 5735 447 EMail: john-ietf@jck.com 449 Intellectual Property Statement 451 The IETF takes no position regarding the validity or scope of any 452 Intellectual Property Rights or other rights that might be claimed to 453 pertain to the implementation or use of the technology described in 454 this document or the extent to which any license under such rights 455 might or might not be available; nor does it represent that it has 456 made any independent effort to identify any such rights. Information 457 on the procedures with respect to rights in RFC documents can be 458 found in BCP 78 and BCP 79. 460 Copies of IPR disclosures made to the IETF Secretariat and any 461 assurances of licenses to be made available, or the result of an 462 attempt made to obtain a general license or permission for the use of 463 such proprietary rights by implementers or users of this 464 specification can be obtained from the IETF on-line IPR repository at 465 http://www.ietf.org/ipr. 467 The IETF invites any interested party to bring to its attention any 468 copyrights, patents or patent applications, or other proprietary 469 rights that may cover technology that may be required to implement 470 this standard. Please address the information to the IETF at 471 ietf-ipr@ietf.org. 473 Disclaimer of Validity 475 This document and the information contained herein are provided on an 476 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 477 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 478 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 479 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 480 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 481 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 483 Copyright Statement 485 Copyright (C) The Internet Society (2004). This document is subject 486 to the rights, licenses and restrictions contained in BCP 78, and 487 except as set forth therein, the authors retain all their rights. 489 Acknowledgment 491 Funding for the RFC Editor function is currently provided by the 492 Internet Society. 494 Network Working Group J. Klensin 496 Expires: April 18, 2005 498 Internet Standards Documentation (ISDs) - Examples 499 draft-klensin-newtrk-sample-isd-00.txt 501 Status of this Memo 503 This document is an Internet-Draft and is subject to all provisions 504 of section 3 of RFC 3667. By submitting this Internet-Draft, each 505 author represents that any applicable patent or other IPR claims of 506 which he or she is aware have been or will be disclosed, and any of 507 which he or she become aware will be disclosed, in accordance with 508 RFC 3668. 510 Internet-Drafts are working documents of the Internet Engineering 511 Task Force (IETF), its areas, and its working groups. Note that 512 other groups may also distribute working documents as 513 Internet-Drafts. 515 Internet-Drafts are draft documents valid for a maximum of six months 516 and may be updated, replaced, or obsoleted by other documents at any 517 time. It is inappropriate to use Internet-Drafts as reference 518 material or to cite them other than as "work in progress." 520 The list of current Internet-Drafts can be accessed at 521 http://www.ietf.org/ietf/1id-abstracts.txt. 523 The list of Internet-Draft Shadow Directories can be accessed at 524 http://www.ietf.org/shadow.html. 526 This Internet-Draft will expire on April 18, 2005. 528 Copyright Notice 530 Copyright (C) The Internet Society (2004). 532 Abstract 534 The proposal to define what is actually an IETF standard and to 535 create ways of explaining and qualifying its applicability and 536 relationship to other documents has been described in an 537 Internet-Draft, "Internet Standards Documentation (ISDs)" 538 (draft-ietf-newtrk-repurposing-isd-00). This document provides some 539 examples of what such documents might look like. It includes a very 540 complicated example (SMTP) and a fairly simple one (the IMAP/POP 541 authorization specification of RFC 2195, which has not progressed 542 beyond Proposed Standard). 544 Table of Contents 546 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 547 2. Observations on the Base Document . . . . . . . . . . . . . . 4 548 3. Example 1: The Simple Mail Transfer Protocol . . . . . . . . . 5 549 3.1 SMTP Comments . . . . . . . . . . . . . . . . . . . . . . 5 550 3.2 ISD xxxx: Simple Mail Transfer Protocol, SMTP . . . . . . 5 551 3.2.1 Documents making up the Standard, STD10 . . . . . . . 5 552 3.2.2 Additional Relevant Documents . . . . . . . . . . . . 6 553 3.2.3 Extensions to the SMTP Base Specification . . . . . . 6 554 3.2.4 Related ISDs (temporary) . . . . . . . . . . . . . . . 7 555 3.2.5 Experimental Extensions . . . . . . . . . . . . . . . 8 556 3.2.6 Comments on Related Documents . . . . . . . . . . . . 8 557 3.2.7 History and Tracking Information . . . . . . . . . . . 10 558 4. Example 2: POP/IMAP Authentication with CRAM-MD5 . . . . . . . 11 559 4.1 POP/AUTH CRAM-MD5 Comments . . . . . . . . . . . . . . . . 11 560 4.2 ISD yyyy: POP/IMAP Authentication with CRAM-MD5, 561 CRAM-MD5 . . . . . . . . . . . . . . . . . . . . . . . . . 11 562 5. Security Considerations and Other Boilerplate . . . . . . . . 12 563 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 564 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 565 6.2 Informative References . . . . . . . . . . . . . . . . . . . 13 566 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 567 Intellectual Property and Copyright Statements . . . . . . . . 14 569 1. Introduction 571 The proposal to define what is actually an IETF standard and to 572 create ways of explaining and qualifying its applicability and 573 relationship to other documents has been described in an 574 Internet-Draft, "Internet Standards Documentation (ISDs)" 575 [ISD-definition]. This document provides some examples of what such 576 documents might look like. It includes a very complicated example 577 (SMTP) and a fairly simple one (the IMAP/POP authorization 578 specification of RFC 2195 [RFC2195], which has not progressed beyond 579 Proposed Standard). 581 It is worth stressing that little effort has been made to check most 582 of the statements in the examples for accuracy; they were constructed 583 from the author's (failing) memory only. 585 If a successor to the ISD proposal document is ultimately approved, 586 the examples here should evolve into actual ISD documents; this 587 document itself is not expected to evolve into an RFC of any type. 589 Due to some issues with tools (or the author's lack of familiarity 590 with them), no attempt has been made to get the formating of the 591 sample documents correct in this draft. I prefer the format used in 592 Scott Bradner's treatment of the standards process document. What is 593 here should be enough to stimulate a discussion of content; perhaps 594 the format can be upgraded at -01. 596 Let the quibbling begin ! 598 2. Observations on the Base Document 600 As expected, constructing examples such as there was a learning 601 experience. Even for something as complex as SMTP and its 602 extensions, putting together a skeleton ISD took only a couple of 603 hours. It does require some familiarity with the relevant protocols; 604 it would probaby not be practical for someone without that 605 familiarity to put something together without a lot of work. 607 The classifications, groupings, and comments below are probably 608 controversial but, in some respects, that is exactly the point: if we 609 aren't able to agree on grouping of these things, they should either 610 remain separate or we should be explicit about our disagreements. Of 611 course, as new documents and specifications are developed within the 612 ISD context, authors, editors, and WGs should be expected to make 613 recommendations about grouping. 615 3. Example 1: The Simple Mail Transfer Protocol 617 3.1 SMTP Comments 619 SMTP was chosen because it is one of the more heavily-used protocols 620 on the Internet and because the notion of a "complete implementation" 621 is both controversial and requires reference to a significant number 622 of documents. The effort, with RFC 2821 [RFC2821], to clean up the 623 multiple-document situation was a success in some respects, but the 624 large number of extensions which that document did not (or could not) 625 address have put us back into a situation as serious as the one we 626 had before the 2821/2822 ("DRUMS") effort started. 628 The relationships of the various documents remains controversial, and 629 the comments below are strictly the opinion of the author. Resolving 630 them for a real ISD document is one of the challenges of the ISD 631 approavh. However, the author's opinion is that either the IETF can 632 reach consensus on those issues or it cannot. Pretending that it can 633 when that is not the case is ultimately not useful; it would be 634 preferable to simply note the lack of consensus and move on, as the 635 example's discussion of the extensions attempts to do. 637 3.2 ISD xxxx: Simple Mail Transfer Protocol, SMTP 639 Abstract: The Simple Mail Transfer Protocol, more commonly know as 640 just "SMTP", is the Internet's primary standard protocol for the 641 transport of electronic mail between hosts. The long-time standard 642 version was described in RFC 821, which was updated or clarified in 643 several documents. Revisions and extensions during the 1990s updated 644 the original specification with an extension mechanism and a number 645 of clarifications, creating what is sometimes described as "modern" 646 or "contemporary" SMTP. This ISD specifies the SMTP protocol as it 647 is now understood and provides a collection of references to 648 extensions that are not, themselves, part of the standard. 650 3.2.1 Documents making up the Standard, STD10 652 RFC2821 653 Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001. 654 (Status: PROPOSED STANDARD) 655 This is the current base specification for SMTP. Some earlier 656 implementations still legitimately claim conformance only to 657 RFC821, which represents an earlier state of STMP implementations. 658 All implementations that are fully-conformant to RFC 821 and the 659 standards-track documents that qualified, clarified, or updated 660 it, should be compatible with RFC 2821 and this standard, even 661 though they do not support the newer features. RFC 2821 makes 662 RFC0821, RFC0974, and RFC1869 obsolete; those documents are 663 described in the "history" section below (Section 3.2.7). 664 Verified errata: 665 * Section 4.5.5 contains a doubled instance of the word "with". 666 * In Section 3.7, the uses of the word "their" in the sentence 667 "Many historical problems with their interpretation have made 668 their use undesirable." refers to source routes, not MX 669 records. 670 Other putative errata: The RFC Editor has a list of outstanding 671 errata for RFC2821 which, other than those above, are unverified. 672 These can be found by entering the RFC number into the "errata" 673 search page located from http://www.rfc-editor.org/. 675 3.2.2 Additional Relevant Documents 677 RFC3463 678 Enhanced Mail System Status Codes. G. Vaudreuil. January 2003. 679 Status: DRAFT STANDARD 680 This document specifies a code system for providing more 681 specificity than the codes specified (and required) by RFC 2821 682 and the older 821. The codes are used in addition to the 683 classical codes, but do not replace them. Their generation in 684 SMTP server (receiver) implementations is strongly encouraged; 685 SMTP clients can take advantage of them to report additional 686 information to users. Some of the extensions listed below require 687 the use of these codes (see RFC 2034 in particular). 688 The document was updated by RFC3886, which specifies some 689 additional codes. Some of the extensions below also specify 690 additional codes. 691 RFC3848 692 ESMTP and LMTP Transmission Types Registration. C. Newman. July 693 2004. 694 Status: PROPOSED STANDARD 695 This document describes additional transmission type codes for use 696 in the Received: header field inserted by SMTP servers. 697 [[Note in draft: Probably a separate ISD with a cross-reference.]] 699 3.2.3 Extensions to the SMTP Base Specification 701 RFC1652 702 SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N. 703 Freed, M. Rose, E. Stefferud, D. Crocker. July 1994. 704 Status: DRAFT STANDARD) 705 This extension is required if 8-bit characters are to be 706 transported, without additional encoding (e.g., with a MIME 707 content-transfer-encoding) in SMTP. It is widely implemented and 708 supported and has been found, for obvious reasons, to be useful. 709 Its "downgrading" options are less widely supported, but become 710 gradually less important as the mechanism is deployed. 712 Posted errata: None 713 RFC1870 714 SMTP Service Extension for Message Size Declaration. J. Klensin, 715 N. Freed, K. Moore. November 1995. 716 Status: STANDARD) 717 This is a full standard and even more widely supported than the 718 8-Bit-MIME specification discussed above. Support and 719 implementation are strongly recommended. 720 Posted errata: None 721 RFC2920 722 SMTP Service Extension for Command Pipelining. N. Freed. 723 September 2000. 724 Status: STANDARD) 725 Posted errata: None 726 [[Note in draft: This is a full standard, currently STD0060. I 727 think it is really an optional to implement, but commonly deployed 728 and recommended, part of SMTP.]] 729 RFC2034 730 SMTP Service Extension for Returning Enhanced Error Codes. N. 731 Freed. October 1996. 732 Status: PROPOSED STANDARD 733 Provides a specific model for use of enhanced reply codes (see 734 above). 735 RFC2554 736 SMTP Service Extension for Authentication. J. Myers. March 737 1999. 738 Status: PROPOSED STANDARD) 739 This is the base "SMTP AUTH" specification, now supported by most 740 clients and servers and required in several environments. 741 [[Note in draft: Something needs to be said about the SASL efforts 742 here, see discussion in Section 4]]. 743 RFC3207 744 SMTP Service Extension for Secure SMTP over Transport Layer 745 Security. P. Hoffman. February 2002. 746 Status: PROPOSED STANDARD 747 RFC3030 748 SMTP Service Extensions for Transmission of Large and Binary MIME 749 Messages. G. Vaudreuil. December 2000. 750 Status: PROPOSED STANDARD 751 Putative errata: The RFC Editor has a list of outstanding errata 752 for RFC3030 that are unverified. These can be found by entering 753 the RFC number into the "errata" search page located from 754 http://www.rfc-editor.org/. 756 3.2.4 Related ISDs (temporary) 758 The following documents or document sets should be turned into 759 separate ISDs and then referenced from some sort of "additional 760 references" section here. 762 SMTP Delivery Status Notifications (DSN) 763 The specification of delivery status notifications for email 764 consist of a number of separate documents, and are covered in a 765 separate definition, ISD zzzz. 766 [[Note in draft: or this author got too lazy. RFCs 3461, 3798, 767 3885, 2852, and probably some others, plus a discussion of the DSN 768 message format, which probably also belongs in the same ISD. The 769 message tracking materials of RFC 3885 and the additional 770 notification format material in RFC 3798 probably belong there 771 too, or in yet another ISD.]] 772 SMTP and SPAM (SMTP-SPAM) 773 There are several different documents covering SMTP-based methods 774 for spam control. These are covered in a separate definition, ISD 775 zyzy. 776 [[Note in draft: or this author got too lazy. RFCs 2505 and 3865 777 probably belong in separate ISDs since neither depends in any way 778 on the other for implementation.]] 779 On-demand relay, delivery, and alternatives to TURN 780 There are several different documents covering methods by which a 781 client machine, or a third party, can start delivery of a message 782 queue from an SMTP server. These are covered in a separate 783 definition, ISD yzyz. 784 [[Note in draft: or this author got too lazy. RFCs 1985 and 2645 785 probably belong in separate ISDs since neither depends in any way 786 on the other for implementation.]] 788 3.2.5 Experimental Extensions 790 These extensions are included for reference and information only. 791 The IETF has not concluded that they are ready for standards-track 792 treatment and deficiencies may be known but not documented formally. 794 RFC1830 795 SMTP Service Extensions for Transmission of Large and Binary MIME 796 Messages. G. Vaudreuil. August 1995. (Obsoleted by RFC3030) 797 Status: EXPERIMENTAL) 798 RFC1845 799 SMTP Service Extension for Checkpoint/Restart. D. Crocker, N. 800 Freed, A. Cargille. September 1995. 801 Status: EXPERIMENTAL) 803 3.2.6 Comments on Related Documents 805 This section discusses some documents that preceed the first ISD 806 publication of a document describing this standard, so dates are not 807 given. 809 RFC0821 810 Simple Mail Transfer Protocol. J. Postel. Aug-01-1982. 811 (Obsoletes RFC0788) (Obsoleted by RFC2821) (Also STD0010). 812 Superceded in practice by RFC 2821, as described above. 813 RFC0974 814 Mail routing and the domain system. C. Partridge. Jan-01-1986. 815 This document was incorporated into SMTP and made mandatory by RFC 816 1123. Its substance has been incorporated into RFC 2821 and the 817 document itself classified as historic. 818 RFC1869 819 SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E. 820 Stefferud, D. Crocker. November 1995. 821 (Status: STANDARD). 822 This document and its predecessors defined the extension mechanism 823 for SMTP and imposed the requirement that fully-conforming SMTP 824 implementations support those mechanisms. All of its functional 825 capabilities were incorporated into RFC 2821. 826 RFC1047 827 Duplicate messages and SMTP. C. Partridge. Feb-01-1988. 828 (Status: UNKNOWN) 829 The substance of this document is believed to have been 830 incorporated into RFC 2821. 831 RFC1090 832 SMTP on X.25. R. Ullmann. Feb-01-1989. 833 (Status: UNKNOWN) 834 This protocol is generally considered obsolete. X.25 itself is 835 falling into disuse and most use of SMTP in X.25 environments 836 involves a TCP/IP transport over X.25, then running SMTP normally 837 over TCP. 838 [[Note in draft to Cruft Committee (see [NewtrkHistoric]), if any: 839 this one is low-hanging fruit.]] 840 RFC1428 841 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME. 842 G. Vaudreuil. February 1993. 843 Status: INFORMATIONAL 844 This document provided important transitional information but, a 845 decade later, the transitional problem appears to have been 846 largely solved and the consenus among most SMTP implementors and 847 implementations is that "just send 8" implementions are broken. 848 RFC1846 849 SMTP 521 Reply Code. A. Durand, F. Dupont. September 1995. 850 Status: EXPERIMENTAL 851 The IETF, in the process of constructing RFC 2821, reviewed this 852 model and proposal and decided to not incorporate exactly what it 853 proposed. RFC 2821 is authoritative on the 521 reply code. 855 3.2.7 History and Tracking Information 857 ...To be supplied... 859 [[Note in draft: A discussion of just what belongs here, e.g., dates 860 and the nature of the change, or complete previous information of 861 documents that have been removed/obsoleted as Scott's "standards 862 process" document does, would be helpful.]] 864 4. Example 2: POP/IMAP Authentication with CRAM-MD5 866 4.1 POP/AUTH CRAM-MD5 Comments 868 This one ought to be a simple case, since it is associated with only 869 a single current document (and one that it quickly rendered 870 obsolete), but it raises some interesting issues. One is how to 871 construct a name/acronym, since this is most commonly known by names 872 that don't appear in the title of the RFC. Another is what, if 873 anything to say about the effort to supercede this with a SASL 874 mechanism: when that is done, the ISD document will be an appropriate 875 place to note and describe the relationship but, until then... 877 4.2 ISD yyyy: POP/IMAP Authentication with CRAM-MD5, CRAM-MD5 879 Abstract: While IMAP4 supports a number of strong authentication 880 mechanisms as described in RFC 1731, it lacks any mechanism that 881 neither passes cleartext, reusable passwords across the network nor 882 requires either a significant security infrastructure or that the 883 mail server update a mail-system-wide user authentication file on 884 each mail access. This specification provides a simple 885 challenge-response authentication protocol that is suitable for use 886 with IMAP4. Since it utilizes Keyed-MD5 digests and does not require 887 that the secret be stored in the clear on the server, it may also 888 constitute an improvement on APOP for POP3 use as specified in RFC 889 1734. 891 RFC Reference: RFC 2195 IMAP/POP AUTHorize Extension for Simple 892 Challenge/Response. J. Klensin, R. Catoe, P. Krumviede. 893 September 1997. 895 Status: PROPOSED STANDARD 897 This protocol is widely supported in both clients and servers and is 898 required by a number of major ISPs. 900 5. Security Considerations and Other Boilerplate 902 As discusssed in [ISD-definition], security considerations and 903 similar material may not be appropriate for ISDs, or may apply to 904 individual components that make up the ISD rather than the standard 905 in total. See that document for further discussion. 907 6. References 909 6.1 Normative References 911 [ISD-definition] 912 Klensin, J. and J. Loughney, "Internet Standards 913 Documentation (ISDs)", 914 draft-ietf-newtrk-repurposing-isd-00 (work in progress), 915 September 2004. 917 [RFC2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP 918 AUTHorize Extension for Simple Challenge/Response", RFC 919 2195, September 1997. 921 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 922 April 2001. 924 6.2 Informative References 926 [NewtrkHistoric] 927 Alvestrand, H. and E. Lear, "Getting rid of the cruft: A 928 procedure to deprecate old standards", 929 draft-ietf-newtrk-cruft-00 (work in progress), October 930 2004. 932 Author's Address 934 John C Klensin 935 1770 Massachusetts Ave, #322 936 Cambridge, MA 02140 937 USA 939 Phone: +1 617 491 5735 940 EMail: john-ietf@jck.com 942 Intellectual Property Statement 944 The IETF takes no position regarding the validity or scope of any 945 Intellectual Property Rights or other rights that might be claimed to 946 pertain to the implementation or use of the technology described in 947 this document or the extent to which any license under such rights 948 might or might not be available; nor does it represent that it has 949 made any independent effort to identify any such rights. Information 950 on the procedures with respect to rights in RFC documents can be 951 found in BCP 78 and BCP 79. 953 Copies of IPR disclosures made to the IETF Secretariat and any 954 assurances of licenses to be made available, or the result of an 955 attempt made to obtain a general license or permission for the use of 956 such proprietary rights by implementers or users of this 957 specification can be obtained from the IETF on-line IPR repository at 958 http://www.ietf.org/ipr. 960 The IETF invites any interested party to bring to its attention any 961 copyrights, patents or patent applications, or other proprietary 962 rights that may cover technology that may be required to implement 963 this standard. Please address the information to the IETF at 964 ietf-ipr@ietf.org. 966 Disclaimer of Validity 968 This document and the information contained herein are provided on an 969 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 970 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 971 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 972 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 973 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 974 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 976 Copyright Statement 978 Copyright (C) The Internet Society (2004). This document is subject 979 to the rights, licenses and restrictions contained in BCP 78, and 980 except as set forth therein, the authors retain all their rights. 982 Acknowledgment 984 Funding for the RFC Editor function is currently provided by the 985 Internet Society.