idnits 2.17.1 draft-moonesamy-rfc2369bis-01.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 4, 2012) is 4468 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-00 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 4, 2012 4 Obsoletes: 2369 (if approved) 5 Intended status: Standards Track 6 Expires: July 7, 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-01 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 the 18 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 and List-Archive. 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 7, 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. Note . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 2. The Command Syntax . . . . . . . . . . . . . . . . . . . . . . 4 83 3. The List Header Fields . . . . . . . . . . . . . . . . . . . . 6 84 3.1. List-Help . . . . . . . . . . . . . . . . . . . . . . . . 6 85 3.2. List-Unsubscribe . . . . . . . . . . . . . . . . . . . . . 7 86 3.3. List-Subscribe . . . . . . . . . . . . . . . . . . . . . . 8 87 3.4. List-Post . . . . . . . . . . . . . . . . . . . . . . . . 8 88 3.5. List-Owner . . . . . . . . . . . . . . . . . . . . . . . . 9 89 3.6. List-Archive . . . . . . . . . . . . . . . . . . . . . . . 9 90 3.7. List-Sequence . . . . . . . . . . . . . . . . . . . . . . 10 91 3.8. List-Id . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 4. Supporting Nested Lists . . . . . . . . . . . . . . . . . . . 11 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 95 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 97 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 98 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 99 Appendix A. Client Implementation . . . . . . . . . . . . . . . . 13 100 A.1. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 13 101 A.2. Implementation Options . . . . . . . . . . . . . . . . . . 13 102 A.2.1. Key combinations and command lines . . . . . . . . . . 14 103 A.2.2. Menu items . . . . . . . . . . . . . . . . . . . . . . 14 104 A.2.3. Push Buttons and Pallettes . . . . . . . . . . . . . . 14 105 A.2.4. Feedback to the User . . . . . . . . . . . . . . . . . 14 106 Appendix B. Changes from RFC 2369 . . . . . . . . . . . . . . . . 14 107 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 15 108 C.1. Changes between between version -00 and version -01 . . . 15 109 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 111 1. Introduction 113 RFC 2369 [RFC2369] defined additional header fields to be added to 114 email messages sent by mailing list managers (MLMs). The content of 115 each new header field is typically a URI [RFC3986] - usually mailto 116 [RFC6068] - which identifies the relevant information or performs the 117 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. 127 The description of command syntax provided by the header fields can 128 be used by mail user agents (MUAs) to provide simplified and 129 consistent user access to mailing list functions. This could take 130 the form of menu items, push buttons, or other user interface 131 elements. The intent is to simplify the user experience, providing a 132 common interface to the often cryptic and varied mailing list manager 133 commands. 135 Consideration has been given to avoiding the creation of too many 136 header fields, while at the same time avoiding the overloading of 137 individual header fields and keeping the syntax clear and simple. 139 The use of these header fields does not remove the requirement to 140 support the -Request command address for mailing lists [RFC2142]. 142 This document obsoletes RFC 2369 [RFC2369]. 144 1.1. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 1.2. Note 152 This Internet-Draft can be discussed on the apps-discuss@ietf.org 153 mailing list. [RFC-Editor: please remove this paragraph] 155 2. The Command Syntax 157 The list header fields are subject to the encoding and character 158 restrictions for mail headers fields as described in [RFC5322]. 160 The contents of the list header fields mostly consist of angle- 161 bracket ('<', '>') enclosed URIs [RFC3986], with internal whitespace 162 being ignored. mailing list managers MUST NOT insert whitespace 163 within the brackets. Client applications SHOULD treat any 164 whitespace, that might be inserted by poorly behaved mailing list 165 managers, as characters to ignore. 167 A list of multiple, alternate, URIs MAY be specified by a comma- 168 separated list of angle-bracket enclosed URIs. The URIs have order 169 of preference from left to right. The client application should use 170 the left most protocol that it supports, or knows how to access by a 171 separate application. By this mechanism, protocols like http may be 172 specified while still providing the basic mailto support for those 173 clients who do not have access to non-mail protocols. The client 174 should only use one of the available URIs for a command, using 175 another only if the first one used failed. 177 The use of URIs allows for the use of the syntax with existing URI 178 supporting applications. As the standard for URIs is extended, the 179 list header fields will gain the benefit of those extensions. 180 Additionally, the use of URIs provides access to multiple transport 181 protocols (such as ftp and http) although it is expected that the 182 "mailto" protocol [RFC6068] will be the focus of most use of the list 183 header fields. Use of non-mailto protocols should be considered in 184 light of those users who do not have access to the specified 185 mechanism (those who only have email - with no web access). 187 Command syntaxes requiring variable fields to be set by the client 188 (such as including the user's email address within a command) are not 189 supported by this implementation. However, mailing list managers 190 using such syntaxes should still take advantage of the List-Help 191 field to provide the user with detailed instructions as needed or - 192 perhaps more usefully - provide access to some form of structured 193 command interface such as an HTML-based form. 195 The additional complications of supporting variable fields within the 196 command syntax was determined to be too difficult to support by this 197 protocol and would compromise the likelihood of implementation by 198 software authors. 200 To allow for future extension, it is recommended that client 201 applications follow the guidelines below for handling the contents of 202 the header fields described in this document: 204 1. Except where noted for specific header fields, if the content of 205 the header field (following any leading whitespace, including 206 comments) begins with any character other than the opening angle 207 bracket '<', the header field SHOULD be ignored. 209 2. Any characters following an angle bracket enclosed URI SHOULD be 210 ignored, unless a comma is the first non-whitespace/comment 211 character after the closing angle bracket. 213 3. If a sub-item (comma-separated item) within the field is not an 214 angle-bracket enclosed URI, the remainder of the field (the 215 current, and all subsequent, sub-items) SHOULD be ignored. 217 3. The List Header Fields 219 This document presents header fields which will provide the command 220 syntax description for the 'core' and key secondary functions of most 221 mailing list managers. The header fields implemented on a given 222 mailing list SHOULD be included on all messages distributed by the 223 list (including command responses to individual users), and on other 224 messages where the message clearly applies to one distinct mailing 225 list. There MUST be no more than one of each header field present in 226 any given message. 228 These header fields MUST only be generated by mailing list managers, 229 not by MUAs. Mailing list managers generating the list header fields 230 SHOULD include a mailto based command, in addition to any other 231 protocols used, in order to support users who do not have access to 232 non-mail-based protocols. 234 3.1. List-Help 236 The List-Help header field is the most important of the header fields 237 described in this document. It is acceptable for a mailing list 238 manager to include only this header field, since by definition it can 239 direct the user to complete instructions for all other commands. 240 Typically, the URI specified would request the help file, perhaps 241 incorporating an HTML form for list commands, for the list, and 242 alternatively provide access to an instructive website. 244 Examples: 246 List-Help: (List 247 Instructions) 249 List-Help: 251 List-Help: (Info about the list) 253 List-Help: , 254 256 List-Help: (FTP), 257 259 3.2. List-Unsubscribe 261 The List-Unsubscribe header field describes the command (preferably 262 using mail) to directly unsubscribe the user (removing them from the 263 list). 265 Examples: 267 List-Unsubscribe: 268 270 List-Unsubscribe: (Use this command to get off the list) 271 273 List-Unsubscribe: 274 List-Unsubscribe: 275 , 276 278 3.3. List-Subscribe 280 The List-Subscribe header field describes the command (preferably 281 using mail) to directly subscribe the user (request addition to the 282 list). 284 Examples: 286 List-Subscribe: 287 289 List-Subscribe: (Use this command to join the list) 290 292 List-Subscribe: 294 List-Subscribe: 295 , 296 298 3.4. List-Post 300 The List-Post header field describes the method for posting to the 301 mailing list. This is typically the email address of the mailing 302 list. It can also be the email address of a moderator, or 303 potentially some other form of submission. For the special case of a 304 mailing list that does not allow posting (e.g., an announcements 305 list), the List-Post field may contain the special value "NO". 307 Examples: 309 List-Post: 311 List-Post: (Postings are 312 Moderated) 314 List-Post: 315 317 List-Post: NO (posting not allowed on this list) 319 3.5. List-Owner 321 The List-Owner header field identifies the path to contact a human 322 administrator for the mailing list. The URI may contain the email 323 address of an administrator for the mailing list, the mail system 324 administrator, or any other person who can handle user contact for 325 the mailing list. There is no need to specify List-Owner if it is 326 the same person as the mail system administrator (postmaster). 328 Examples: 330 List-Owner: (Contact Person for 331 Help) 333 List-Owner: (Grant Neufeld) 335 List-Owner: 337 3.6. List-Archive 339 The List-Archive header field describes how to access archives for 340 the mailing list. 342 Examples: 344 List-Archive: 345 347 List-Archive: 349 List-Archive: (Web 350 Archive) 352 List-Archive: 354 The Archive-At header field [RFC5064] provides a pointer to an 355 archived form of a single message. 357 3.7. List-Sequence 359 The List-Sequence header field provides a Sequence Identifier for 360 each message sent to a mailing list. While this is often expressed 361 as an integer, it is not constrained to be so. Nor is it constrained 362 to fit into a 31- or 32-bit integer when it is an integral value. 363 The Sequence Identifier SHOULD be unique within a mailing list. 364 There MUST NOT be more than one List-Sequence header field in any 365 given message. 367 The syntax [RFC5322] for a Sequence Identifier (seq-id) is as 368 follows: 370 seq-id = 1*atext 372 Examples: 374 List-Sequence: 5 376 List-Sequence: S25 378 3.8. List-Id 380 The List-Id header field provides an identifier for an e-mail 381 distribution list [I-D.moonesamy-rfc2919bis]. 383 4. Supporting Nested Lists 385 A mailing list that is a sublist for another mailing list in a nested 386 mailing list hierarchy will need to modify some of the List- header 387 fields, while leaving others as the parent list set them. 389 Sublists SHOULD remove the parent list's List-Help, List-Subscribe, 390 List-Unsubscribe and List-Owner header fields, and SHOULD insert 391 their own versions of those header fields. 393 If the sublist provides its own archive, it SHOULD replace the List- 394 Archive and List-Sequence header fields with its own. Otherwise, it 395 MUST leave the List-Archive and List-Sequence header fields 396 untouched. 398 Dependant on how postings to the mailing list are handled, the 399 sublist MAY replace the List-Post field. The appropriateness of 400 whether to replace List-Post is left to the determination of the 401 individual list administrators. If the intention is that postings 402 should be distributed to all members of the primary mailing list, 403 List-Post should not be changed by a sublist in such a way that 404 postings will be distributed only to members of the sublist. 406 5. Security Considerations 408 There are very few new security concerns generated with this 409 proposal. Message headers fields are an existing standard, designed 410 to easily accommodate new types. There may be concern with multiple 411 header fields being inserted or headers fields being forged, but 412 these are problems inherent in Internet mail, not specific to this 413 specification. Furthermore, the implications are relatively 414 harmless. 416 Mailing list managers should not allow any user-originated list 417 header fields to pass through to the mailing lists, lest they confuse 418 the user and have the potential to create security problems. 420 On the client side, there may be some concern with posts or commands 421 being sent in error. It is required that the user have a chance to 422 confirm any action before it is executed. In the case of mailto, it 423 may be appropriate to create the correctly formatted message without 424 sending it, allowing the user to see exactly what is happening and 425 giving the user the opportunity to approve or discard the message 426 before it is sent. 428 All security considerations for the use of URIs [RFC3986] apply 429 equally to this specification. Mail User Agents should not process 430 list header field URIs which could compromise the security of the 431 user's system. This includes the "file://" URI type which could 432 potentially be used to trigger the execution of a local application 433 on some user systems. 435 6. IANA Considerations 437 The List-Archive, List-Help, List-Owner, List-Post, List-Subscribe, 438 and List-Unsubscribe references in the Permanent Message Header Field 439 Names registry should be updated to point to this document. 441 7. Acknowledgements 443 Most of the text in this document was copied from RFC 2369, authored 444 by Joshua D. Baer and Grant Neufeld. 446 The numerous participants of the List-Header, ListMom-Talk, List- 447 Managers and MIDA-Mail mailing lists contributed much to the 448 formation and structure of RFC 2369 with Keith Moore and Christopher 449 Allen providing guidance on the standards process. 451 Tony Hansen contributed to the List-Sequence section. 453 8. References 455 8.1. Normative References 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 461 Resource Identifier (URI): Generic Syntax", STD 66, 462 RFC 3986, January 2005. 464 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 465 October 2008. 467 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 468 URI Scheme", RFC 6068, October 2010. 470 8.2. Informative References 472 [I-D.moonesamy-rfc2919bis] 473 Moonesamy, S., "List-Id: A Structured Field and Namespace 474 for the Identification of Mailing Lists", 475 draft-moonesamy-rfc2919bis-00 (work in progress), 476 December 2011. 478 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 479 FUNCTIONS", RFC 2142, May 1997. 481 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 482 for Core Mail List Commands and their Transport through 483 Message Header Fields", RFC 2369, July 1998. 485 [RFC5064] Duerst, M., "The Archived-At Message Header Field", 486 RFC 5064, December 2007. 488 Appendix A. Client Implementation 490 A.1. Guidelines 492 For 'mailto' URI based commands, Mail User Agents may choose to 493 provide specialized feedback (such as presenting a dialog or alert), 494 instead of the actual command email message, asking for command 495 confirmation from the user. The feedback should identify the message 496 destination and command within a more descriptive explanation. For 497 example: 499 "Do you want to send the unsubscription command 'unsubscribe 500 somelist' to 'somelist-request@some.example.com'? Sending the 501 command will result in your removal from the associated list." 503 If the user has multiple email addresses supported by the Mail User 504 Agent, the MUA should prompt the user for which email address to use 505 when subscribing or performing some other action where the email 506 address to use cannot be specifically determined. When unsubscribing 507 or such, the email address that is subscribed should be used, unless 508 that is not known by the application and cannot be determined from 509 the message headers. 511 A.2. Implementation Options 513 The following implementation possibilities are suggested here to give 514 some idea as to why these new header fields will be useful, and how 515 they could be supported. 517 In most cases, it may be helpful to disable the interface for the 518 commands when not applicable to the currently selected message. 520 A.2.1. Key combinations and command lines 522 On text based systems which utilize command lines or key 523 combinations, each field could be implemented as a separate command. 524 Thus one combination would subscribe the user, another would 525 unsubscribe, a third request help, etc. The commands would only be 526 available on messages containing the list header fields. 528 A.2.2. Menu items 530 On graphical systems which have menus, these commands could take the 531 form of a menu or sub-menu of items. For example, a "Lists" menu 532 might appear when viewing messages containing the header fields, with 533 items named "Subscribe", "Unsubscribe", "Get Help", "Post Message to 534 List", "Contact List Owner" and "Access List Archive". This menu 535 could be disabled when not applicable to the current message or 536 disappear entirely. 538 A.2.3. Push Buttons and Pallettes 540 On graphical window systems, buttons could be placed in the window of 541 the message, a toolbar, or in a floating pallette of their own. Each 542 button could correspond to a command, with names "Subscribe", 543 "Unsubscribe", "Get Help", "Post to List", "List Owner" and 544 "Archive". These buttons or pallettes could be disabled when not 545 applicable to the current message or disappear entirely. 547 A.2.4. Feedback to the User 549 If using a dialog interface (or other feedback element) the mail user 550 agent must include an option for the user to review (and possibly 551 modify) the message before it is sent. It may also be useful for 552 mail user agents to provide a link to more detailed context- 553 sensitive assistance about mailing list access in general. 555 Appendix B. Changes from RFC 2369 557 This appendix contains a list of changes between this document and 558 RFC 2369. 560 o URL changed to URI 562 o Replaced MTAs with mailing list managers in the sentence: "MTAs 563 generating the header fields SHOULD". 565 o Replaced MTAs with mailing list managers in the sentence: "MTAs 566 MUST NOT insert whitespace within the brackets" in Section 2 568 o In Section 2, client application SHOULD ignore whitespace within 569 brackets 571 o Updated references 573 o Added informative reference to RFC 5064 575 o Editorial changes 577 o Removed Background Discussion 579 Appendix C. Change Log 581 [RFC-Editor: please remove this section] 583 C.1. Changes between between version -00 and version -01 585 o Added List-Sequence header field 587 o Added informative reference to I-D.moonesamy-rfc2919bis 589 Author's Address 591 S. Moonesamy (editor) 592 76, Ylang Ylang Avenue 593 Quatre Bornes 594 Mauritius 596 Email: sm+ietf@elandsys.com