idnits 2.17.1 draft-moonesamy-rfc2369bis-04.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 (February 20, 2012) is 4441 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 February 20, 2012 6 Expires: August 23, 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-04 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 August 23, 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 4. Supporting Nested Lists . . . . . . . . . . . . . . . . . . . 10 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 83 Appendix A. Implementation . . . . . . . . . . . . . . . . . . . 12 84 Appendix B. Changes from RFC 2369 . . . . . . . . . . . . . . . . 12 85 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 12 86 C.1. Changes between between version -03 and version -04 . . . 12 87 C.2. Changes between between version -02 and version -03 . . . 13 88 C.3. Changes between between version -01 and version -02 . . . 13 89 C.4. Changes between between version -00 and version -01 . . . 13 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 92 1. Introduction 94 RFC 2369 [RFC2369] defined additional header fields to be added to 95 email messages sent by mailing list managers (MLMs). The significant 96 change in this document is the use of Uniform Resource Identifier 97 (URI) [RFC3986], instead of Uniform Resource Locator (URL), allowing 98 an implementation to parse the common components of a URI reference 99 without knowing the scheme-specific requirements of every possible 100 identifier. The content of each new header field is typically a URI 101 - usually "mailto" [RFC6068] - which identifies the relevant 102 information or performs the command directly. 104 These headers fields are optional. Significant functionality and 105 convenience can be gained by including them. The List-Help header 106 field provides an access point to detailed user support information, 107 and accommodates almost all existing mailing list managers command 108 sets. The List-Subscribe and List-Unsubscribe header fields provide 109 access to two functions commonly requested by mailing list 110 subscribers. 112 The description of command syntax provided by the header fields can 113 be used by mail user agents (MUAs) to provide simplified and 114 consistent user access to mailing list functions. The intent is to 115 simplify the user experience, providing a common interface to the 116 often cryptic and varied mailing list manager commands. 118 Consideration has been given to avoiding the creation of too many 119 header fields, while at the same time avoiding the overloading of 120 individual header fields and keeping the syntax clear and simple. 122 The use of these header fields does not remove the requirement to 123 support the -Request command address for mailing lists [RFC2142]. 125 This document obsoletes RFC 2369 [RFC2369]. 127 1.1. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 1.2. Syntax Notation 135 This specification uses the Augmented Backus-Naur Form (ABNF) 136 [RFC5234] notation for the formal definitions of the syntax of list 137 header fields. 139 1.3. Note 141 This Internet-Draft can be discussed on the apps-discuss@ietf.org 142 mailing list. [RFC-Editor: please remove this paragraph] 144 2. The Command Syntax 146 The list header fields are subject to the encoding and character 147 restrictions for mail headers fields as described in [RFC5322]. 149 The contents of the list header fields mostly consist of angle- 150 bracket ('<', '>') enclosed URIs [RFC3986], with internal whitespace 151 being ignored. mailing list managers MUST NOT insert whitespace 152 within the brackets. Client applications SHOULD treat any 153 whitespace, that might be inserted by poorly behaved mailing list 154 managers, as characters to ignore. 156 A list of multiple, alternate, URIs MAY be specified by a comma- 157 separated list of angle-bracket enclosed URIs. The URIs have order 158 of preference from left to right. The client application should use 159 the left most scheme that it supports, or knows how to access by a 160 separate application. With this mechanism, schemes like http may be 161 specified while still providing the basic "mailto" support for those 162 clients who do not have access to non-mail scheme. The client should 163 only use one of the available URIs for a command, using another only 164 if the first one used failed. 166 The use of URIs allows for the use of the syntax with existing URI 167 supporting applications. As the standard for URIs is extended, the 168 list header fields will gain the benefit of those extensions. 169 Additionally, the use of URIs provides access to multiple schemes 170 (such as ftp and http) although it is expected that the "mailto" 171 scheme [RFC6068] will be the focus of most use of the list header 172 fields. Use of the schemes should be considered in light of those 173 users who do not have access to the specified mechanism. 175 Command syntaxes requiring variable fields to be set by the client 176 (such as including the user's email address within a command) are not 177 supported by this implementation. However, mailing list managers 178 using such syntaxes should still take advantage of the List-Help 179 field to provide the user with detailed instructions as needed or - 180 perhaps more usefully - provide access to some form of structured 181 command interface such as an HTML-based form. 183 The additional complications of supporting variable fields within the 184 command syntax was determined to be too difficult to support by this 185 protocol and would compromise the likelihood of implementation by 186 software authors. 188 To allow for future extension, it is recommended that client 189 applications follow the guidelines below for handling the contents of 190 the header fields described in this document: 192 1. Except where noted for specific header fields, if the content of 193 the header field (following any leading whitespace, including 194 comments) begins with any character other than the opening angle 195 bracket '<', the header field SHOULD be ignored. 197 2. Any characters following an angle bracket enclosed URI SHOULD be 198 ignored, unless a comma is the first non-whitespace/comment 199 character after the closing angle bracket. 201 3. If a sub-item (comma-separated item) within the field is not an 202 angle-bracket enclosed URI, the remainder of the field (the 203 current, and all subsequent, sub-items) SHOULD be ignored. 205 3. The List Header Fields 207 This document presents header fields which will provide the command 208 syntax description for the 'core' and key secondary functions of most 209 mailing list managers. The header fields implemented on a given 210 mailing list SHOULD be included on all messages distributed by the 211 list (including command responses to individual users), and on other 212 messages where the message clearly applies to one distinct mailing 213 list. There MUST be no more than one of each header field present in 214 any given message. 216 These header fields MUST only be generated by mailing list managers, 217 not by MUAs. 219 3.1. List-Help 221 The List-Help header field can direct the user to complete 222 instructions for all other commands. Typically, the URI specified 223 would request the help file, perhaps incorporating an HTML form for 224 list commands, for the list, and alternatively provide access to an 225 instructive website. 227 Syntax: 229 uri-list = "<" URI ">" *("," [ FWS ] "<" URI ">") 231 ; whereas is defined in RFC 3986 and and 232 ; in RFC 5322 234 ; CRLF is the carriage return/line feed pair 236 list-help = "List-Help:" [ CFWS ] uri-list [ CFWS ] CRLF 238 Examples: 240 List-Help: (List 241 Instructions) 243 List-Help: 245 List-Help: (Info about the list) 247 List-Help: , 248 250 List-Help: (FTP), 251 253 3.2. List-Unsubscribe 255 The List-Unsubscribe header field describes the command to directly 256 unsubscribe the user (removing them from the list). 258 Syntax: 260 list-unsubscribe = "List-Unsubscribe:" uri-list [ CFWS ] CRLF 262 Examples: 264 List-Unsubscribe: 265 267 List-Unsubscribe: (Use this command to get off the list) 268 270 List-Unsubscribe: 272 List-Unsubscribe: 273 , 274 276 3.3. List-Subscribe 278 The List-Subscribe header field describes the command to directly 279 subscribe the user (request addition to the list). 281 Syntax: 283 list-subscribe = "List-Subscribe:" uri-list [ CFWS ] CRLF 285 Examples: 287 List-Subscribe: 288 290 List-Subscribe: (Use this command to join the list) 291 293 List-Subscribe: 295 List-Subscribe: 296 , 297 299 3.4. List-Post 301 The List-Post header field describes the method for posting to the 302 mailing list. This is typically the email address of the mailing 303 list. It can also be the email address of a moderator, or 304 potentially some other form of submission. For the special case of a 305 mailing list that does not allow posting (e.g., an announcements 306 list), the List-Post field may contain the special value "NO". 308 Syntax: 310 list-post = "List-Post:" uri-list/"NO" [ CFWS ] CRLF 312 Examples: 314 List-Post: 316 List-Post: (Postings are 317 Moderated) 319 List-Post: 320 322 List-Post: NO (posting not allowed on this list) 324 3.5. List-Owner 326 The List-Owner header field identifies the path to contact a human 327 administrator for the mailing list. The URI may contain the email 328 address of an administrator for the mailing list, the mail system 329 administrator, or any other person who can handle user contact for 330 the mailing list. 332 Syntax: 334 list-owner = "List-Owner:" uri-list [ CFWS ] CRLF 336 Examples: 338 List-Owner: (Contact Person for 339 Help) 341 List-Owner: (Grant Neufeld) 343 List-Owner: 345 3.6. List-Archive 347 The List-Archive header field describes how to access archives for 348 the mailing list. 350 Syntax: 352 list-archive = "List-Archive:" uri-list [ CFWS ] CRLF 354 Examples: 356 List-Archive: 357 359 List-Archive: 361 List-Archive: (Web 362 Archive) 364 List-Archive: 366 The Archive-At header field [RFC5064] provides a pointer to an 367 archived form of a single message. 369 4. Supporting Nested Lists 371 A mailing list that is a sublist for another mailing list in a nested 372 mailing list hierarchy will need to modify some of the List- header 373 fields, while leaving others as the parent list set them. 375 Sublists SHOULD remove the parent list's List-Help, List-Subscribe, 376 List-Unsubscribe and List-Owner header fields, and SHOULD insert 377 their own versions of those header fields. 379 If the sublist provides its own archive, it SHOULD replace the List- 380 Archive header field with its own. Otherwise, it MUST leave the 381 List-Archive header field untouched. 383 Dependant on how postings to the mailing list are handled, the 384 sublist MAY replace the List-Post field. The appropriateness of 385 whether to replace List-Post is left to the determination of the 386 individual list administrators. If the intention is that postings 387 should be distributed to all members of the primary mailing list, 388 List-Post should not be changed by a sublist in such a way that 389 postings will be distributed only to members of the sublist. 391 5. Security Considerations 393 There are very few new security concerns generated with this 394 proposal. Message headers fields are an existing standard, designed 395 to easily accommodate new types. There may be concern with multiple 396 header fields being inserted or headers fields being forged, but 397 these are problems inherent in Internet mail, not specific to this 398 specification. 400 Mailing list managers should not allow any user-originated list 401 header fields to pass through to the mailing lists, lest they confuse 402 the user and have the potential to create security problems. 404 On the client side, there may be some concern with posts or commands 405 being sent in error. It is required that the user have a chance to 406 confirm any action before it is executed. In the case of "mailto", 407 it may be appropriate to create the correctly formatted message 408 without sending it, allowing the user to see exactly what is 409 happening and giving the user the opportunity to approve or discard 410 the message before it is sent. 412 All security considerations for the use of URIs [RFC3986] apply 413 equally to this specification. Mail User Agents should not process 414 list header field URIs which could compromise the security of the 415 user's system. This includes the "file://" URI type which could 416 potentially be used to trigger the execution of a local application 417 on some user systems. 419 6. IANA Considerations 421 The List-Archive, List-Help, List-Owner, List-Post, List-Subscribe, 422 and List-Unsubscribe references in the Permanent Message Header Field 423 Names registry should be updated to point to this document. 425 7. Acknowledgements 427 The numerous participants of the List-Header, ListMom-Talk, List- 428 Managers and MIDA-Mail mailing lists contributed much to the 429 formation and structure of RFC 2369 with Keith Moore and Christopher 430 Allen providing guidance on the standards process. 432 We would like to thank the the following people for their 433 contributions: Mykyta Yevstifeye, Murray S. Kucherawy and John 434 Levine. 436 8. References 438 8.1. Normative References 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, March 1997. 443 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 444 Resource Identifier (URI): Generic Syntax", STD 66, 445 RFC 3986, January 2005. 447 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 448 Specifications: ABNF", STD 68, RFC 5234, January 2008. 450 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 451 October 2008. 453 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 454 URI Scheme", RFC 6068, October 2010. 456 8.2. Informative References 458 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 459 FUNCTIONS", RFC 2142, May 1997. 461 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 462 for Core Mail List Commands and their Transport through 463 Message Header Fields", RFC 2369, July 1998. 465 [RFC5064] Duerst, M., "The Archived-At Message Header Field", 466 RFC 5064, December 2007. 468 Appendix A. Implementation 470 RFC 2369 contains a discussion about the design decisions for List- 471 header fields. 473 Appendix B. Changes from RFC 2369 475 This appendix contains a list of changes between this document and 476 RFC 2369. 478 o URL changed to URI 480 o Replaced MTAs with mailing list managers in the sentence: "MTAs 481 generating the header fields SHOULD". 483 o Replaced MTAs with mailing list managers in the sentence: "MTAs 484 MUST NOT insert whitespace within the brackets" in Section 2 486 o In Section 2, client application SHOULD ignore whitespace within 487 brackets 489 o Updated references 491 o Added informative reference to RFC 5064 493 o Editorial changes 495 o Removed Background Discussion 497 Appendix C. Change Log 499 [RFC-Editor: please remove this section] 501 C.1. Changes between between version -03 and version -04 503 o Removed sections about List-ID and List-Sequence as they are not 504 URIs 506 C.2. Changes between between version -02 and version -03 508 o Added Grant Neufeld as co-author 510 o Added Joshua Baer as co-author 512 o Move List-Sequence header field definition to I-D.moonesamy- 513 rfc2919bis 515 C.3. Changes between between version -01 and version -02 517 o Added ABNF and reference to RFC 5234 519 o Removed text about postmaster in List-Owner Section 521 o Removed User Interface guidelines from Appendix B 523 o Removed SHOULD include a "mailto" based command in Section 3 525 o Modified the text to first paragraph of Section 3.1 527 C.4. Changes between between version -00 and version -01 529 o Added List-Sequence header field 531 o Added informative reference to I-D.moonesamy-rfc2919bis 533 Authors' Addresses 535 S. Moonesamy (editor) 536 76, Ylang Ylang Avenue 537 Quatre Bornes 538 Mauritius 540 Email: sm+ietf@elandsys.com 542 Grant Neufeld 543 Calgary, Alberta 544 Canada 546 Email: grant@grantneufeld.ca 547 Joshua Baer 548 Austin, Texas 549 USA 551 Email: ietf@joshuabaer.com 552 URI: http://joshuabaer.com/