idnits 2.17.1 draft-moonesamy-rfc2369bis-03.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 date (January 23, 2012) is 4476 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-02 Summary: 0 errors (**), 0 flaws (~~), 2 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 G. Neufeld 4 Obsoletes: 2369 (if approved) J. Baer 5 Intended status: Standards Track January 23, 2012 6 Expires: July 26, 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-03 12 Abstract 14 The mailing list command specification and identification header 15 fields are a set of structured fields to be added to email messages 16 sent by email distribution lists. Command header fields typically 17 contain URIs (usually including "mailto") locating the relevant 18 information or performing the command directly. The three core 19 command header fields described in this document are List-Help, List- 20 Subscribe, and List-Unsubscribe. 22 There are three other header fields described here which, although 23 not as widely applicable, will have utility for a sufficient number 24 of mailing lists to justify their formalization here. These are 25 List-Post, List-Owner and List-Archive. 27 By including these header fields, mailing list managers can make it 28 possible for mail user agents to provide automated tools for users to 29 perform list functions. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 26, 2012. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 3 67 1.3. Note . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. The Command Syntax . . . . . . . . . . . . . . . . . . . . . . 4 69 3. The List Header Fields . . . . . . . . . . . . . . . . . . . . 5 70 3.1. List-Help . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. List-Unsubscribe . . . . . . . . . . . . . . . . . . . . . 6 72 3.3. List-Subscribe . . . . . . . . . . . . . . . . . . . . . . 7 73 3.4. List-Post . . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.5. List-Owner . . . . . . . . . . . . . . . . . . . . . . . . 8 75 3.6. List-Archive . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.7. List-Sequence . . . . . . . . . . . . . . . . . . . . . . 10 77 3.8. List-Id . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 4. Supporting Nested Lists . . . . . . . . . . . . . . . . . . . 10 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 85 Appendix A. Implementation . . . . . . . . . . . . . . . . . . . 12 86 Appendix B. Changes from RFC 2369 . . . . . . . . . . . . . . . . 12 87 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 13 88 C.1. Changes between between version -02 and version -03 . . . 13 89 C.2. Changes between between version -01 and version -02 . . . 13 90 C.3. Changes between between version -00 and version -01 . . . 13 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 93 1. Introduction 95 RFC 2369 [RFC2369] defined additional header fields to be added to 96 email messages sent by mailing list managers (MLMs). The significant 97 change in this document is the use of Uniform Resource Identifier 98 (URI) [RFC3986], instead of Uniform Resource Locator (URL), allowing 99 an implementation to parse the common components of a URI reference 100 without knowing the scheme-specific requirements of every possible 101 identifier. The content of each new header field is typically a URI 102 - usually "mailto" [RFC6068] - which identifies the relevant 103 information or performs the command directly. 105 These headers fields are optional. Significant functionality and 106 convenience can be gained by including them. The List-Help header 107 field provides an access point to detailed user support information, 108 and accommodates almost all existing mailing list managers command 109 sets. The List-Subscribe and List-Unsubscribe header fields provide 110 access to two functions commonly requested by mailing list 111 subscribers. 113 The description of command syntax provided by the header fields can 114 be used by mail user agents (MUAs) to provide simplified and 115 consistent user access to mailing list functions. The intent is to 116 simplify the user experience, providing a common interface to the 117 often cryptic and varied mailing list manager commands. 119 Consideration has been given to avoiding the creation of too many 120 header fields, while at the same time avoiding the overloading of 121 individual header fields and keeping the syntax clear and simple. 123 The use of these header fields does not remove the requirement to 124 support the -Request command address for mailing lists [RFC2142]. 126 This document obsoletes RFC 2369 [RFC2369]. 128 1.1. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 1.2. Syntax Notation 136 This specification uses the Augmented Backus-Naur Form (ABNF) 137 [RFC5234] notation for the formal definitions of the syntax of list 138 header fields. 140 1.3. Note 142 This Internet-Draft can be discussed on the apps-discuss@ietf.org 143 mailing list. [RFC-Editor: please remove this paragraph] 145 2. The Command Syntax 147 The list header fields are subject to the encoding and character 148 restrictions for mail headers fields as described in [RFC5322]. 150 The contents of the list header fields mostly consist of angle- 151 bracket ('<', '>') enclosed URIs [RFC3986], with internal whitespace 152 being ignored. mailing list managers MUST NOT insert whitespace 153 within the brackets. Client applications SHOULD treat any 154 whitespace, that might be inserted by poorly behaved mailing list 155 managers, as characters to ignore. 157 A list of multiple, alternate, URIs MAY be specified by a comma- 158 separated list of angle-bracket enclosed URIs. The URIs have order 159 of preference from left to right. The client application should use 160 the left most scheme that it supports, or knows how to access by a 161 separate application. With this mechanism, schemes like http may be 162 specified while still providing the basic "mailto" support for those 163 clients who do not have access to non-mail scheme. The client should 164 only use one of the available URIs for a command, using another only 165 if the first one used failed. 167 The use of URIs allows for the use of the syntax with existing URI 168 supporting applications. As the standard for URIs is extended, the 169 list header fields will gain the benefit of those extensions. 170 Additionally, the use of URIs provides access to multiple schemes 171 (such as ftp and http) although it is expected that the "mailto" 172 scheme [RFC6068] will be the focus of most use of the list header 173 fields. Use of the schemes should be considered in light of those 174 users who do not have access to the specified mechanism. 176 Command syntaxes requiring variable fields to be set by the client 177 (such as including the user's email address within a command) are not 178 supported by this implementation. However, mailing list managers 179 using such syntaxes should still take advantage of the List-Help 180 field to provide the user with detailed instructions as needed or - 181 perhaps more usefully - provide access to some form of structured 182 command interface such as an HTML-based form. 184 The additional complications of supporting variable fields within the 185 command syntax was determined to be too difficult to support by this 186 protocol and would compromise the likelihood of implementation by 187 software authors. 189 To allow for future extension, it is recommended that client 190 applications follow the guidelines below for handling the contents of 191 the header fields described in this document: 193 1. Except where noted for specific header fields, if the content of 194 the header field (following any leading whitespace, including 195 comments) begins with any character other than the opening angle 196 bracket '<', the header field SHOULD be ignored. 198 2. Any characters following an angle bracket enclosed URI SHOULD be 199 ignored, unless a comma is the first non-whitespace/comment 200 character after the closing angle bracket. 202 3. If a sub-item (comma-separated item) within the field is not an 203 angle-bracket enclosed URI, the remainder of the field (the 204 current, and all subsequent, sub-items) SHOULD be ignored. 206 3. The List Header Fields 208 This document presents header fields which will provide the command 209 syntax description for the 'core' and key secondary functions of most 210 mailing list managers. The header fields implemented on a given 211 mailing list SHOULD be included on all messages distributed by the 212 list (including command responses to individual users), and on other 213 messages where the message clearly applies to one distinct mailing 214 list. There MUST be no more than one of each header field present in 215 any given message. 217 These header fields MUST only be generated by mailing list managers, 218 not by MUAs. 220 3.1. List-Help 222 The List-Help header field can direct the user to complete 223 instructions for all other commands. Typically, the URI specified 224 would request the help file, perhaps incorporating an HTML form for 225 list commands, for the list, and alternatively provide access to an 226 instructive website. 228 Syntax: 230 uri-list = "<" URI ">" *("," [ FWS ] "<" URI ">") 232 ; whereas is defined in RFC 3986 and and 233 ; in RFC 5322 235 ; CRLF is the carriage return/line feed pair 237 list-help = "List-Help:" [ CFWS ] uri-list [ CFWS ] CRLF 239 Examples: 241 List-Help: (List 242 Instructions) 244 List-Help: 246 List-Help: (Info about the list) 248 List-Help: , 249 251 List-Help: (FTP), 252 254 3.2. List-Unsubscribe 256 The List-Unsubscribe header field describes the command to directly 257 unsubscribe the user (removing them from the list). 259 Syntax: 261 list-unsubscribe = "List-Unsubscribe:" uri-list [ CFWS ] CRLF 263 Examples: 265 List-Unsubscribe: 266 268 List-Unsubscribe: (Use this command to get off the list) 269 271 List-Unsubscribe: 273 List-Unsubscribe: 274 , 275 277 3.3. List-Subscribe 279 The List-Subscribe header field describes the command to directly 280 subscribe the user (request addition to the list). 282 Syntax: 284 list-subscribe = "List-Subscribe:" uri-list [ CFWS ] CRLF 286 Examples: 288 List-Subscribe: 289 291 List-Subscribe: (Use this command to join the list) 292 294 List-Subscribe: 296 List-Subscribe: 297 , 298 300 3.4. List-Post 302 The List-Post header field describes the method for posting to the 303 mailing list. This is typically the email address of the mailing 304 list. It can also be the email address of a moderator, or 305 potentially some other form of submission. For the special case of a 306 mailing list that does not allow posting (e.g., an announcements 307 list), the List-Post field may contain the special value "NO". 309 Syntax: 311 list-post = "List-Post:" uri-list/"NO" [ CFWS ] CRLF 313 Examples: 315 List-Post: 317 List-Post: (Postings are 318 Moderated) 320 List-Post: 321 323 List-Post: NO (posting not allowed on this list) 325 3.5. List-Owner 327 The List-Owner header field identifies the path to contact a human 328 administrator for the mailing list. The URI may contain the email 329 address of an administrator for the mailing list, the mail system 330 administrator, or any other person who can handle user contact for 331 the mailing list. 333 Syntax: 335 list-owner = "List-Owner:" uri-list [ CFWS ] CRLF 337 Examples: 339 List-Owner: (Contact Person for 340 Help) 342 List-Owner: (Grant Neufeld) 344 List-Owner: 346 3.6. List-Archive 348 The List-Archive header field describes how to access archives for 349 the mailing list. 351 Syntax: 353 list-archive = "List-Archive:" uri-list [ CFWS ] CRLF 355 Examples: 357 List-Archive: 358 360 List-Archive: 362 List-Archive: (Web 363 Archive) 365 List-Archive: 367 The Archive-At header field [RFC5064] provides a pointer to an 368 archived form of a single message. 370 3.7. List-Sequence 372 The List-Sequence header field provides a standard location for 373 identifying the sequence position of an individual message for a 374 mailing list [I-D.moonesamy-rfc2919bis]. 376 3.8. List-Id 378 The List-Id header field provides an identifier for an e-mail 379 distribution list [I-D.moonesamy-rfc2919bis]. 381 4. Supporting Nested Lists 383 A mailing list that is a sublist for another mailing list in a nested 384 mailing list hierarchy will need to modify some of the List- header 385 fields, while leaving others as the parent list set them. 387 Sublists SHOULD remove the parent list's List-Help, List-Subscribe, 388 List-Unsubscribe and List-Owner header fields, and SHOULD insert 389 their own versions of those header fields. 391 If the sublist provides its own archive, it SHOULD replace the List- 392 Archive header field with its own. Otherwise, it MUST leave the 393 List-Archive header field untouched. 395 Dependant on how postings to the mailing list are handled, the 396 sublist MAY replace the List-Post field. The appropriateness of 397 whether to replace List-Post is left to the determination of the 398 individual list administrators. If the intention is that postings 399 should be distributed to all members of the primary mailing list, 400 List-Post should not be changed by a sublist in such a way that 401 postings will be distributed only to members of the sublist. 403 5. Security Considerations 405 There are very few new security concerns generated with this 406 proposal. Message headers fields are an existing standard, designed 407 to easily accommodate new types. There may be concern with multiple 408 header fields being inserted or headers fields being forged, but 409 these are problems inherent in Internet mail, not specific to this 410 specification. 412 Mailing list managers should not allow any user-originated list 413 header fields to pass through to the mailing lists, lest they confuse 414 the user and have the potential to create security problems. 416 On the client side, there may be some concern with posts or commands 417 being sent in error. It is required that the user have a chance to 418 confirm any action before it is executed. In the case of "mailto", 419 it may be appropriate to create the correctly formatted message 420 without sending it, allowing the user to see exactly what is 421 happening and giving the user the opportunity to approve or discard 422 the message before it is sent. 424 All security considerations for the use of URIs [RFC3986] apply 425 equally to this specification. Mail User Agents should not process 426 list header field URIs which could compromise the security of the 427 user's system. This includes the "file://" URI type which could 428 potentially be used to trigger the execution of a local application 429 on some user systems. 431 6. IANA Considerations 433 The List-Archive, List-Help, List-Owner, List-Post, List-Subscribe, 434 and List-Unsubscribe references in the Permanent Message Header Field 435 Names registry should be updated to point to this document. 437 7. Acknowledgements 439 The numerous participants of the List-Header, ListMom-Talk, List- 440 Managers and MIDA-Mail mailing lists contributed much to the 441 formation and structure of RFC 2369 with Keith Moore and Christopher 442 Allen providing guidance on the standards process. 444 We would like to thank the the following people for their 445 contributions: Mykyta Yevstifeye, Murray S. Kucherawy and John 446 Levine. 448 8. References 450 8.1. Normative References 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 456 Resource Identifier (URI): Generic Syntax", STD 66, 457 RFC 3986, January 2005. 459 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 460 Specifications: ABNF", STD 68, RFC 5234, January 2008. 462 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 463 October 2008. 465 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 466 URI Scheme", RFC 6068, October 2010. 468 8.2. Informative References 470 [I-D.moonesamy-rfc2919bis] 471 Moonesamy, S., "List-Id: A Structured Field and Namespace 472 for the Identification of Mailing Lists", 473 draft-moonesamy-rfc2919bis-02 (work in progress), 474 January 2012. 476 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 477 FUNCTIONS", RFC 2142, May 1997. 479 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 480 for Core Mail List Commands and their Transport through 481 Message Header Fields", RFC 2369, July 1998. 483 [RFC5064] Duerst, M., "The Archived-At Message Header Field", 484 RFC 5064, December 2007. 486 Appendix A. Implementation 488 RFC 2369 contains a discussion about the design decisions for List- 489 header fields. 491 Appendix B. Changes from RFC 2369 493 This appendix contains a list of changes between this document and 494 RFC 2369. 496 o URL changed to URI 498 o Replaced MTAs with mailing list managers in the sentence: "MTAs 499 generating the header fields SHOULD". 501 o Replaced MTAs with mailing list managers in the sentence: "MTAs 502 MUST NOT insert whitespace within the brackets" in Section 2 504 o In Section 2, client application SHOULD ignore whitespace within 505 brackets 507 o Updated references 509 o Added informative reference to RFC 5064 511 o Editorial changes 513 o Removed Background Discussion 515 Appendix C. Change Log 517 [RFC-Editor: please remove this section] 519 C.1. Changes between between version -02 and version -03 521 o Added Grant Neufeld as co-author 523 o Added Joshua Baer as co-author 525 o Move List-Sequence header field definition to I-D.moonesamy- 526 rfc2919bis 528 C.2. Changes between between version -01 and version -02 530 o Added ABNF and reference to RFC 5234 532 o Removed text about postmaster in List-Owner Section 534 o Removed User Interface guidelines from Appendix B 536 o Removed SHOULD include a "mailto" based command in Section 3 538 o Modified the text to first paragraph of Section 3.1 540 C.3. Changes between between version -00 and version -01 542 o Added List-Sequence header field 544 o Added informative reference to I-D.moonesamy-rfc2919bis 546 Authors' Addresses 548 S. Moonesamy (editor) 549 76, Ylang Ylang Avenue 550 Quatre Bornes 551 Mauritius 553 Email: sm+ietf@elandsys.com 555 Grant Neufeld 556 Calgary, Alberta 557 Canada 559 Email: grant@grantneufeld.ca 561 Joshua Baer 562 Austin, Texas 563 USA 565 Email: ietf@joshuabaer.com 566 URI: http://joshuabaer.com/