idnits 2.17.1 draft-moonesamy-rfc2919bis-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document obsoletes RFC2919, 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 4442 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) == Missing Reference: 'ID.moonesamy-rfc2369bis' is mentioned on line 96, but not defined == Unused Reference: 'I-D.moonesamy-rfc2369bis' is defined on line 358, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-moonesamy-rfc2369bis-03 Summary: 0 errors (**), 0 flaws (~~), 5 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 4 Obsoletes: 2919 (if approved) R. Chandhok 5 Intended status: Standards Track G. Wenger 6 Expires: August 23, 2012 QUALCOMM, Inc. 7 February 20, 2012 9 List-Id: A Structured Field and Namespace for the Identification of 10 Mailing Lists 11 draft-moonesamy-rfc2919bis-04 13 Abstract 15 Software that handles electronic mailing list messages (servers and 16 user agents) needs a way to reliably identify messages that belong to 17 a particular mailing list. With the advent of list header fields, it 18 has become even more important to provide a unique identifier for a 19 mailing list regardless of the particular host that runs the mailing 20 list manager at any given time. 22 The List-Id header field provides a standard location for such an 23 identifier. In addition, a namespace for mailing list identifiers 24 based on fully qualified domain names is described. This namespace 25 is intended to guarantee uniqueness for list owners who require it, 26 while allowing for a less rigorous namespace for experimental and 27 personal use. 29 By including the List-Id field, mailing list managers can make it 30 easier for mail user agents to provide automated tools for users to 31 perform mailing list functions. The mailing list identifier can 32 serve as a key for automated processing tasks 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 23, 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 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 70 1.3. Note . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. List Identifier Syntax . . . . . . . . . . . . . . . . . . . . 5 72 3. List-Id Header Field . . . . . . . . . . . . . . . . . . . . . 6 73 4. Persistence of List Identifiers . . . . . . . . . . . . . . . 7 74 5. Uniqueness of List Identifiers . . . . . . . . . . . . . . . . 7 75 6. Operations on List Identifier . . . . . . . . . . . . . . . . 8 76 7. Supporting Nested Lists . . . . . . . . . . . . . . . . . . . 8 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 82 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 83 Appendix A. Subject Tags . . . . . . . . . . . . . . . . . . . . 10 84 Appendix B. Changes from RFC 2919 . . . . . . . . . . . . . . . . 10 85 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 11 86 C.1. Changes between between version -03 and version -04 . . . 11 87 C.2. Changes between between version -02 and version -03 . . . 11 88 C.3. Changes between between version -01 and version -02 . . . 11 89 C.4. Changes between between version -00 and version -01 . . . 11 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 92 1. Introduction 94 Internet mailing lists have evolved into fairly sophisticated forums 95 for group communication and collaboration. draft-moonesamy-rfc2369bis 96 [ID.moonesamy-rfc2369bis] expands the functionality that the Mail 97 User Agent (MUA) can provide by providing more information in each 98 message sent by the mailing list manager (MLM). 100 Implementing such functionality in the MUA depends on the ability to 101 accurately identify messages as belonging to a particular mailing 102 list. The problem then becomes what attribute or property to use to 103 identify a mailing list. The most likely candidate is the submission 104 address of the mailing list itself. Unfortunately, when the server 105 where the mailing list manager is hosted or the submission policy of 106 the list changes the submission address itself can change. This 107 affects automated processing and filtering of messages from mailing 108 lists. 110 In order to further automate (and make more accurate) the processing 111 a software agent can do, RFC 2919 [RFC2919] specified how to generate 112 a unique identifier for a mailing list. This identifier can be 113 simply used for string matching in a filter, or it can be used in 114 more sophisticated systems to uniquely identify messages as belonging 115 to a particular mailing list independent of the particular host 116 delivering the actual messages. This identifier can also act as a 117 key into a database of mailing lists. 119 This document obsoletes RFC 2919 [RFC2919]. 121 1.1. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 1.2. Syntax Notation 129 This specification uses the Augmented Backus-Naur Form (ABNF) 130 [RFC5234] notation for the formal definitions of the syntax of list 131 header fields. 133 1.3. Note 135 This Internet-Draft can be discussed on the apps-discuss@ietf.org 136 mailing list. [RFC-Editor: please remove this paragraph] 138 2. List Identifier Syntax 140 The List Identifier will, in most cases, appear like a host name in a 141 domain of the list owner. Using the domain name space as a basis for 142 the List Identifier namespace, it is intended to leverage an existing 143 name space structure to generate a unique identifier. It also allows 144 for the List Identifier to be kept separate from any particular 145 delivery host or mechanism. 147 While it is perfectly acceptable for a List Identifier to be 148 completely independent of the domain name of the host machine 149 servicing the mailing list, the owner of a mailing list MUST NOT 150 generate List Identifiers in any domain name space for which they do 151 not have authority. For example, a mailing list hosting service may 152 choose to assign List Identifiers in their own domain-based name 153 space, or they may allow their clients (the list owners) to provide 154 List Identifiers in a namespace for which the owner has authority. 156 If the owner of the mailing list does not have the authority to 157 create a List Identifier in a domain-based name space, they may 158 create unmanaged List Identifiers in the special unmanaged domain 159 "invalid". 161 Syntax: 163 list-id = list-label "." list-id-namespace 165 list-label = dot-atom-text 167 list-id-namespace = domain-name / unmanaged-list-id-namespace 169 unmanaged-list-id-namespace = "invalid" 171 domain-name = dot-atom-text 173 Where: 175 dot-atom-text is defined in [RFC5322] 177 "invalid" is a reserved domain name defined in [RFC2606] 179 In addition, a List Identifier (list-id) MUST NOT be longer than 255 180 octets in length, for future compatibility. It should be noted that 181 "invalid" is not valid for the domain-name rule. 183 3. List-Id Header Field 185 This document specifies a List-Id header field which will provide an 186 identifier for a mailing list. This header field should be included 187 on all messages distributed by the mailing list manager (including 188 command responses to individual users), and on other messages where 189 the message clearly applies to this particular distinct mailing list. 190 There MUST be not be more than one of List-Id header field in any 191 given message. 193 This field MUST only be generated by mailing list managers, not MUAs. 195 The contents of the List-Id header field mostly consist of angle- 196 bracket ('<', '>') enclosed identifier, with internal whitespace 197 being ignored. Mailing List Managers MUST NOT insert whitespace 198 within the brackets. Client applications SHOULD treat any such 199 whitespace, that might be inserted by poorly behaved mailing list 200 managers, as characters to ignore. 202 The List-Id header field is subject to the encoding and character 203 restrictions for mail headers as described in [RFC5322]. 205 The List-Id header field MAY optionally include a description by 206 including it as a "phrase" [RFC5322] before the angle-bracketed List 207 Identifier. The MUA MAY choose to use this description in its user 208 interface; however, any MUA that intends to make use of the 209 description should be prepared to properly parse and decode any 210 encoded strings or other legal phrase components. For many MUAs the 211 parsing of the List-Id header field will simply consist of extracting 212 the List Identifier from between the delimiting angle brackets. 214 Syntax: 216 list-id-header = "List-Id:" [phrase] "<" list-id ">" CRLF 218 where phrase and CRLF are as defined in [RFC5322]. Unlike most 219 headers fields in RFC 5322 [RFC5322], the List-Id header field does 220 not allow free insertion of whitespace and comments around tokens. 221 Any descriptive text MUST be presented in the optional phrase 222 component of the header field. 224 Examples: 226 List-Id: List Header Mailing List 228 List-Id: 230 List-Id: "Lena's Personal Joke List" 233 List-Id: 235 4. Persistence of List Identifiers 237 Although the List Identifier may be changed by the mailing list 238 administrator, this is not desirable. (Note that there is no 239 disadvantage to changing the description portion of the List-Id 240 header field.) A MUA would not recognize the change to the List 241 Identifier because a MUA treats a different List Identifier as a 242 different list. As such the mailing list administrator should avoid 243 changing the List Identifier even when the host serving the mailing 244 list changes. On the other hand, transitioning from an informal 245 unmanaged-list-id-namespace to a domain name space is an acceptable 246 reason to change the List Identifier. Also if the focus of the 247 mailing list changes sufficiently the administrator may wish to 248 retire the previous mailing list and its associated identifier to 249 start a new mailing list reflecting the new focus. 251 5. Uniqueness of List Identifiers 253 This proposal uses a namespace that by definition can be used to 254 create unique identifiers within the domain. 256 There is a need for identification of mailing lists that are 257 administrated by some entity without administrative access to a 258 domain. In this case, general heuristics can be given to reduce the 259 chance of collision, but it cannot be guaranteed. If a list owner 260 requires a guarantee, they are free to register a domain name under 261 their control. 263 It is suggested, but not required, that List Identifiers be created 264 under a subdomain of "list-id" within any given domain. This can 265 help to reduce internal conflicts between the administrators of the 266 subdomains of large organizations. For example, List Identifiers at 267 "example.com" are generated in the subdomain of "list- 268 id.example.com". 270 A List Identifier not ending with ".invalid" MUST be globally unique 271 in reference to all other mailing lists. List Identifiers ending 272 with ".invalid" are not guaranteed to be globally unique. 274 A List Identifier using the special "invalid" namespace SHOULD 275 include the month and year (in the form MYYYY), i.e. the List 276 Identifier is a "subdomain" of the "invalid" namespace. In addition, 277 some portion of the List Identifier MUST be a randomly generated 278 string, e.g. the random [RFC4086] component contains a hex encoding 279 of 128 bits of randomness (resulting in 32 hex characters) as part of 280 the List Identifier. 282 Thus, List Identifiers such as and 284 follow these 285 guidelines, while and 286 do not. 288 6. Operations on List Identifier 290 There is only one operation defined for List Identifiers, that of 291 case insensitive equality. 293 The sole use of a List Identifier is to identify a mailing list, and 294 the sole use of the List-Id header field is to mark a particular 295 message as belonging to that list. The comparison operation MUST 296 ignore any part of the List-Id header field outside of the angle 297 brackets, the MUA may inform the user if the descriptive name of a 298 mailing list changes. 300 7. Supporting Nested Lists 302 A list that is a sublist for another list in a nested mailing list 303 hierarchy MUST NOT modify the List-Id header field; however, this 304 will only be possible when the nested mailing list is aware of the 305 relationship between it and its "parent" mailing lists. 307 8. Security Considerations 309 There are very few new security concerns generated with this 310 proposal. Message headers fields are an existing standard, designed 311 to easily accommodate new types. There may be concern with multiple 312 header fields being inserted or headers fields being forged, but 313 these are problems inherent in Internet mail, not specific to this 314 specification. If a mailing list manager encounters List-Id header 315 fields from any unexpected source it SHOULD NOT pass them through to 316 the mailing list. 318 As mentioned above, mail list managers should not allow any user- 319 originated List-Id header fields to pass through to their lists, lest 320 they confuse the user and have the potential to create security 321 problems. 323 On the client side, a forged List Identifier may break automated 324 processing. The List Identifier (in its current form) should not be 325 used as an indication of the authenticity of the message. 327 9. IANA Considerations 329 The List-Id reference in the Permanent Message Header Field Names 330 registry should be updated to point to this document. 332 10. Acknowledgements 334 The numerous participants of the List-Header and ListMom-Talk mailing 335 lists contributed much to the formation and structure of this 336 document. 338 Grant Neufeld focused much of the early discussion, and thus was 339 essential in the creation of this document. 341 Murray S. Kucherawy provided insightful comments. 343 11. References 345 11.1. Normative References 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, March 1997. 350 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 351 Specifications: ABNF", STD 68, RFC 5234, January 2008. 353 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 354 October 2008. 356 11.2. Informative References 358 [I-D.moonesamy-rfc2369bis] 359 Moonesamy, S., Neufeld, G., and J. Baer, "The Use of URIs 360 as Meta-Syntax for Core Mail List Commands and their 361 Transport through Message Header Fields", 362 draft-moonesamy-rfc2369bis-03 (work in progress), 363 January 2012. 365 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 366 Names", BCP 32, RFC 2606, June 1999. 368 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 369 and Namespace for the Identification of Mailing Lists", 370 RFC 2919, March 2001. 372 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 373 Requirements for Security", BCP 106, RFC 4086, June 2005. 375 Appendix A. Subject Tags 377 A popular feature of some MLMs is the "tagging" of the Subject header 378 field by prefixing the header field's contents with the name of the 379 mailing list, e.g. "[example]" for a list called "example". The 380 difference between a List Identifier and a subject tag is that while 381 a List Identifier is unique, a subject tag is usually the short form 382 of a mailing list's name. Such a namespace is inherently flat, 383 unmanaged and thus non-unique. 385 Appendix B. Changes from RFC 2919 387 This appendix contains a list of changes between this document and 388 RFC 2919. 390 o Removed text about the domain name system and domain ownership in 391 Section 2 393 o "localhost" replaced with "invalid" 395 o Replaced MTAs with mailing list managers in the sentence: "MTAs 396 MUST NOT insert whitespace within the brackets" in Section 3 398 o Case independence in Section 6 changed to case insensitivity for 399 ASCII 401 o Added a paragraph in the appendix about subject tags 403 o Updated references 405 o Editorial changes 407 Appendix C. Change Log 409 [RFC-Editor: please remove this section] 411 C.1. Changes between between version -03 and version -04 413 o Removed List-Sequence header field as it does not fit it 415 o Reverted recommended to MUST NOT in Section 2 as it is a 416 requirement in RFC 2919 418 C.2. Changes between between version -02 and version -03 420 o Added Ravinder Chandhok as co-author 422 o Added Geoffrey Wenger as co-author 424 C.3. Changes between between version -01 and version -02 426 o Added List-Sequence header field 428 o Removed text about about case-insensitive string comparison 430 o Removed recommendation in Section 4 about how the MUA SHOULD treat 431 a different List Identifier 433 C.4. Changes between between version -00 and version -01 435 o Added informative reference to I-D.moonesamy-rfc2369bis 437 Authors' Addresses 439 S. Moonesamy (editor) 440 76, Ylang Ylang Avenue 441 Quatre Bornes 442 Mauritius 444 Email: sm+ietf@elandsys.com 445 Ravinder Chandhok 446 QUALCOMM, Inc. 447 5775 Morehouse Drive 448 San Diego, CA 92121 449 USA 451 Email: chandhok@qualcomm.com 453 Geoffrey Wenger 454 QUALCOMM, Inc. 455 5775 Morehouse Drive 456 San Diego, CA 92121 457 USA 459 Email: gwenger@qualcomm.com