idnits 2.17.1 draft-moonesamy-rfc2369bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2369, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 18, 2012) is 4481 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-moonesamy-rfc2919bis-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission S. Moonesamy, Ed. 3 Internet-Draft January 18, 2012 4 Obsoletes: 2369 (if approved) 5 Intended status: Standards Track 6 Expires: July 21, 2012 8 The Use of URIs as Meta-Syntax for Core Mail List Commands and their 9 Transport through Message Header Fields 10 draft-moonesamy-rfc2369bis-02 12 Abstract 14 The mailing list command specification header fields are a set of 15 structured fields to be added to email messages sent by email 16 distribution lists. Each header field typically contains a URI 17 (usually "mailto") locating the relevant information or performing 18 the command directly. The three core header fields described in this 19 document are List-Help, List-Subscribe, and List-Unsubscribe. 21 There are three other header fields described here which, although 22 not as widely applicable, will have utility for a sufficient number 23 of mailing lists to justify their formalization here. These are 24 List-Post, List-Owner, List-Archive and List-Sequence. 26 By including these header fields, mailing list managers can make it 27 possible for mail user agents to provide automated tools for users to 28 perform list functions. This could take the form of a menu item, 29 push button, or other user interface element. The intent is to 30 simplify the user experience, providing a common interface to the 31 often cryptic and varied mailing list manager commands. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 21, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 81 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 82 1.3. Note . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 2. The Command Syntax . . . . . . . . . . . . . . . . . . . . . . 5 84 3. The List Header Fields . . . . . . . . . . . . . . . . . . . . 6 85 3.1. List-Help . . . . . . . . . . . . . . . . . . . . . . . . 6 86 3.2. List-Unsubscribe . . . . . . . . . . . . . . . . . . . . . 7 87 3.3. List-Subscribe . . . . . . . . . . . . . . . . . . . . . . 8 88 3.4. List-Post . . . . . . . . . . . . . . . . . . . . . . . . 9 89 3.5. List-Owner . . . . . . . . . . . . . . . . . . . . . . . . 9 90 3.6. List-Archive . . . . . . . . . . . . . . . . . . . . . . . 10 91 3.7. List-Sequence . . . . . . . . . . . . . . . . . . . . . . 11 92 3.8. List-Id . . . . . . . . . . . . . . . . . . . . . . . . . 11 93 4. Supporting Nested Lists . . . . . . . . . . . . . . . . . . . 11 94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 96 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 98 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 99 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 100 Appendix A. Implementation . . . . . . . . . . . . . . . . . . . 14 101 Appendix B. Changes from RFC 2369 . . . . . . . . . . . . . . . . 14 102 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 15 103 C.1. Changes between between version -01 and version -02 . . . 15 104 C.2. Changes between between version -00 and version -01 . . . 15 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 107 1. Introduction 109 RFC 2369 [RFC2369] defined additional header fields to be added to 110 email messages sent by mailing list managers (MLMs). The significant 111 change in this document is the use of Uniform Resource Identifier 112 (URI) [RFC3986], instead of Uniform Resource Locator (URL), allowing 113 an implementation to parse the common components of a URI reference 114 without knowing the scheme-specific requirements of every possible 115 identifier. The content of each new header field is typically a URI 116 - usually "mailto" [RFC6068] - which identifies the relevant 117 information or performs the command directly. 119 These headers fields are optional. Significant functionality and 120 convenience can be gained by including them. The List-Help header 121 field provides an access point to detailed user support information, 122 and accommodates almost all existing mailing list managers command 123 sets. The List-Subscribe and List-Unsubscribe header fields provide 124 access to two functions commonly requested by mailing list 125 subscribers. The List-Sequence header field was added in this 126 document to provide a standard location for a sequence identifier. 128 The description of command syntax provided by the header fields can 129 be used by mail user agents (MUAs) to provide simplified and 130 consistent user access to mailing list functions. The intent is to 131 simplify the user experience, providing a common interface to the 132 often cryptic and varied mailing list manager commands. 134 Consideration has been given to avoiding the creation of too many 135 header fields, while at the same time avoiding the overloading of 136 individual header fields and keeping the syntax clear and simple. 138 The use of these header fields does not remove the requirement to 139 support the -Request command address for mailing lists [RFC2142]. 141 This document obsoletes RFC 2369 [RFC2369]. 143 1.1. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 1.2. Syntax Notation 151 This specification uses the Augmented Backus-Naur Form (ABNF) 152 [RFC5234] notation for the formal definitions of the syntax of list 153 header fields. 155 1.3. Note 157 This Internet-Draft can be discussed on the apps-discuss@ietf.org 158 mailing list. [RFC-Editor: please remove this paragraph] 160 2. The Command Syntax 162 The list header fields are subject to the encoding and character 163 restrictions for mail headers fields as described in [RFC5322]. 165 The contents of the list header fields mostly consist of angle- 166 bracket ('<', '>') enclosed URIs [RFC3986], with internal whitespace 167 being ignored. mailing list managers MUST NOT insert whitespace 168 within the brackets. Client applications SHOULD treat any 169 whitespace, that might be inserted by poorly behaved mailing list 170 managers, as characters to ignore. 172 A list of multiple, alternate, URIs MAY be specified by a comma- 173 separated list of angle-bracket enclosed URIs. The URIs have order 174 of preference from left to right. The client application should use 175 the left most scheme that it supports, or knows how to access by a 176 separate application. With this mechanism, schemes like http may be 177 specified while still providing the basic "mailto" support for those 178 clients who do not have access to non-mail scheme. The client should 179 only use one of the available URIs for a command, using another only 180 if the first one used failed. 182 The use of URIs allows for the use of the syntax with existing URI 183 supporting applications. As the standard for URIs is extended, the 184 list header fields will gain the benefit of those extensions. 185 Additionally, the use of URIs provides access to multiple schemes 186 (such as ftp and http) although it is expected that the "mailto" 187 scheme [RFC6068] will be the focus of most use of the list header 188 fields. Use of the schemes should be considered in light of those 189 users who do not have access to the specified mechanism. 191 Command syntaxes requiring variable fields to be set by the client 192 (such as including the user's email address within a command) are not 193 supported by this implementation. However, mailing list managers 194 using such syntaxes should still take advantage of the List-Help 195 field to provide the user with detailed instructions as needed or - 196 perhaps more usefully - provide access to some form of structured 197 command interface such as an HTML-based form. 199 The additional complications of supporting variable fields within the 200 command syntax was determined to be too difficult to support by this 201 protocol and would compromise the likelihood of implementation by 202 software authors. 204 To allow for future extension, it is recommended that client 205 applications follow the guidelines below for handling the contents of 206 the header fields described in this document: 208 1. Except where noted for specific header fields, if the content of 209 the header field (following any leading whitespace, including 210 comments) begins with any character other than the opening angle 211 bracket '<', the header field SHOULD be ignored. 213 2. Any characters following an angle bracket enclosed URI SHOULD be 214 ignored, unless a comma is the first non-whitespace/comment 215 character after the closing angle bracket. 217 3. If a sub-item (comma-separated item) within the field is not an 218 angle-bracket enclosed URI, the remainder of the field (the 219 current, and all subsequent, sub-items) SHOULD be ignored. 221 3. The List Header Fields 223 This document presents header fields which will provide the command 224 syntax description for the 'core' and key secondary functions of most 225 mailing list managers. The header fields implemented on a given 226 mailing list SHOULD be included on all messages distributed by the 227 list (including command responses to individual users), and on other 228 messages where the message clearly applies to one distinct mailing 229 list. There MUST be no more than one of each header field present in 230 any given message. 232 These header fields MUST only be generated by mailing list managers, 233 not by MUAs. 235 3.1. List-Help 237 The List-Help header field can direct the user to complete 238 instructions for all other commands. Typically, the URI specified 239 would request the help file, perhaps incorporating an HTML form for 240 list commands, for the list, and alternatively provide access to an 241 instructive website. 243 Syntax: 245 uri-list = "<" URI ">" *("," [ FWS ] "<" URI ">") 247 ; whereas is defined in RFC 3986 and and 248 ; in RFC 5322 250 ; CRLF is the carriage return/line feed pair 252 list-help = "List-Help:" [ CFWS ] uri-list [ CFWS ] CRLF 254 Examples: 256 List-Help: (List 257 Instructions) 259 List-Help: 261 List-Help: (Info about the list) 263 List-Help: , 264 266 List-Help: (FTP), 267 269 3.2. List-Unsubscribe 271 The List-Unsubscribe header field describes the command to directly 272 unsubscribe the user (removing them from the list). 274 Syntax: 276 list-unsubscribe = "List-Unsubscribe:" uri-list [ CFWS ] CRLF 278 Examples: 280 List-Unsubscribe: 281 283 List-Unsubscribe: (Use this command to get off the list) 284 286 List-Unsubscribe: 288 List-Unsubscribe: 289 , 290 292 3.3. List-Subscribe 294 The List-Subscribe header field describes the command to directly 295 subscribe the user (request addition to the list). 297 Syntax: 299 list-subscribe = "List-Subscribe:" uri-list [ CFWS ] CRLF 301 Examples: 303 List-Subscribe: 304 306 List-Subscribe: (Use this command to join the list) 307 309 List-Subscribe: 311 List-Subscribe: 312 , 313 315 3.4. List-Post 317 The List-Post header field describes the method for posting to the 318 mailing list. This is typically the email address of the mailing 319 list. It can also be the email address of a moderator, or 320 potentially some other form of submission. For the special case of a 321 mailing list that does not allow posting (e.g., an announcements 322 list), the List-Post field may contain the special value "NO". 324 Syntax: 326 list-post = "List-Post:" uri-list/"NO" [ CFWS ] CRLF 328 Examples: 330 List-Post: 332 List-Post: (Postings are 333 Moderated) 335 List-Post: 336 338 List-Post: NO (posting not allowed on this list) 340 3.5. List-Owner 342 The List-Owner header field identifies the path to contact a human 343 administrator for the mailing list. The URI may contain the email 344 address of an administrator for the mailing list, the mail system 345 administrator, or any other person who can handle user contact for 346 the mailing list. 348 Syntax: 350 list-owner = "List-Owner:" uri-list [ CFWS ] CRLF 352 Examples: 354 List-Owner: (Contact Person for 355 Help) 357 List-Owner: (Grant Neufeld) 359 List-Owner: 361 3.6. List-Archive 363 The List-Archive header field describes how to access archives for 364 the mailing list. 366 Syntax: 368 list-archive = "List-Archive:" uri-list [ CFWS ] CRLF 370 Examples: 372 List-Archive: 373 375 List-Archive: 377 List-Archive: (Web 378 Archive) 380 List-Archive: 382 The Archive-At header field [RFC5064] provides a pointer to an 383 archived form of a single message. 385 3.7. List-Sequence 387 The List-Sequence header field provides a Sequence Identifier for 388 each message sent to a mailing list. While this is often expressed 389 as an integer, it is not constrained to be so. Nor is it constrained 390 to fit into a 31- or 32-bit integer when it is an integral value. 391 The Sequence Identifier SHOULD be unique within a mailing list. 392 There MUST NOT be more than one List-Sequence header field in any 393 given message. 395 Syntax: 397 seq-id = 1*atext 399 list-sequence = "List-Sequence:" seq-id CRLF 401 Examples: 403 List-Sequence: 5 405 List-Sequence: S25 407 3.8. List-Id 409 The List-Id header field provides an identifier for an e-mail 410 distribution list [I-D.moonesamy-rfc2919bis]. 412 4. Supporting Nested Lists 414 A mailing list that is a sublist for another mailing list in a nested 415 mailing list hierarchy will need to modify some of the List- header 416 fields, while leaving others as the parent list set them. 418 Sublists SHOULD remove the parent list's List-Help, List-Subscribe, 419 List-Unsubscribe and List-Owner header fields, and SHOULD insert 420 their own versions of those header fields. 422 If the sublist provides its own archive, it SHOULD replace the List- 423 Archive and List-Sequence header fields with its own. Otherwise, it 424 MUST leave the List-Archive and List-Sequence header fields 425 untouched. 427 Dependant on how postings to the mailing list are handled, the 428 sublist MAY replace the List-Post field. The appropriateness of 429 whether to replace List-Post is left to the determination of the 430 individual list administrators. If the intention is that postings 431 should be distributed to all members of the primary mailing list, 432 List-Post should not be changed by a sublist in such a way that 433 postings will be distributed only to members of the sublist. 435 5. Security Considerations 437 There are very few new security concerns generated with this 438 proposal. Message headers fields are an existing standard, designed 439 to easily accommodate new types. There may be concern with multiple 440 header fields being inserted or headers fields being forged, but 441 these are problems inherent in Internet mail, not specific to this 442 specification. Furthermore, the implications are relatively 443 harmless. 445 Mailing list managers should not allow any user-originated list 446 header fields to pass through to the mailing lists, lest they confuse 447 the user and have the potential to create security problems. 449 On the client side, there may be some concern with posts or commands 450 being sent in error. It is required that the user have a chance to 451 confirm any action before it is executed. In the case of "mailto", 452 it may be appropriate to create the correctly formatted message 453 without sending it, allowing the user to see exactly what is 454 happening and giving the user the opportunity to approve or discard 455 the message before it is sent. 457 All security considerations for the use of URIs [RFC3986] apply 458 equally to this specification. Mail User Agents should not process 459 list header field URIs which could compromise the security of the 460 user's system. This includes the "file://" URI type which could 461 potentially be used to trigger the execution of a local application 462 on some user systems. 464 6. IANA Considerations 466 The List-Archive, List-Help, List-Owner, List-Post, List-Subscribe, 467 and List-Unsubscribe references in the Permanent Message Header Field 468 Names registry should be updated to point to this document. The 469 following is the registration template to add the List-Sequence 470 header field to the Permanent Message Header Field Names registry: 472 Header field name: List-Sequence 474 Applicable protocol: mail ([RFC5322]) 476 Status: Standard 478 Author/Change controller: IETF 480 Specification document(s): RFC XXXX [RFC Editor: please replace 481 XXXX with this RFC number] 483 7. Acknowledgements 485 Most of the text in this document was copied from RFC 2369, authored 486 by Joshua D. Baer and Grant Neufeld. 488 The numerous participants of the List-Header, ListMom-Talk, List- 489 Managers and MIDA-Mail mailing lists contributed much to the 490 formation and structure of RFC 2369 with Keith Moore and Christopher 491 Allen providing guidance on the standards process. 493 Tony Hansen contributed to the List-Sequence section. In addition, I 494 would like to thank the the following people for their contributions: 495 Mykyta Yevstifeye, Murray S. Kucherawy and John Levine. 497 8. References 499 8.1. Normative References 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, March 1997. 504 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 505 Resource Identifier (URI): Generic Syntax", STD 66, 506 RFC 3986, January 2005. 508 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 509 Specifications: ABNF", STD 68, RFC 5234, January 2008. 511 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 512 October 2008. 514 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 515 URI Scheme", RFC 6068, October 2010. 517 8.2. Informative References 519 [I-D.moonesamy-rfc2919bis] 520 Moonesamy, S., "List-Id: A Structured Field and Namespace 521 for the Identification of Mailing Lists", 522 draft-moonesamy-rfc2919bis-01 (work in progress), 523 January 2012. 525 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 526 FUNCTIONS", RFC 2142, May 1997. 528 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 529 for Core Mail List Commands and their Transport through 530 Message Header Fields", RFC 2369, July 1998. 532 [RFC5064] Duerst, M., "The Archived-At Message Header Field", 533 RFC 5064, December 2007. 535 Appendix A. Implementation 537 RFC 2369 contains a discussion about the design decisions for List- 538 header fields. 540 Appendix B. Changes from RFC 2369 542 This appendix contains a list of changes between this document and 543 RFC 2369. 545 o URL changed to URI 547 o Replaced MTAs with mailing list managers in the sentence: "MTAs 548 generating the header fields SHOULD". 550 o Replaced MTAs with mailing list managers in the sentence: "MTAs 551 MUST NOT insert whitespace within the brackets" in Section 2 553 o In Section 2, client application SHOULD ignore whitespace within 554 brackets 556 o Updated references 558 o Added informative reference to RFC 5064 560 o Editorial changes 561 o Removed Background Discussion 563 Appendix C. Change Log 565 [RFC-Editor: please remove this section] 567 C.1. Changes between between version -01 and version -02 569 o Added ABNF and reference to RFC 5234 571 o Removed text about postmaster in List-Owner Section 573 o Removed User Interface guidelines from Appendix B 575 o Removed SHOULD include a "mailto" based command in Section 3 577 o Modified the text to first paragraph of Section 3.1 579 C.2. Changes between between version -00 and version -01 581 o Added List-Sequence header field 583 o Added informative reference to I-D.moonesamy-rfc2919bis 585 Author's Address 587 S. Moonesamy (editor) 588 76, Ylang Ylang Avenue 589 Quatre Bornes 590 Mauritius 592 Email: sm+ietf@elandsys.com