summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2919.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2919.txt')
-rw-r--r--doc/rfc/rfc2919.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc2919.txt b/doc/rfc/rfc2919.txt
new file mode 100644
index 0000000..f2ed316
--- /dev/null
+++ b/doc/rfc/rfc2919.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group R. Chandhok
+Request for Comments: 2919 G. Wenger
+Category: Standards Track QUALCOMM, Inc.
+ March 2001
+
+
+ List-Id:
+ A Structured Field and Namespace for the
+ Identification of Mailing Lists
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ Software that handles electronic mailing list messages (servers and
+ user agents) needs a way to reliably identify messages that belong to
+ a particular mailing list. With the advent of list management
+ headers, it has become even more important to provide a unique
+ identifier for a mailing list regardless of the particular host that
+ serves as the list processor at any given time.
+
+ The List-Id header provides a standard location for such an
+ identifier. In addition, a namespace for list identifiers based on
+ fully qualified domain names is described. This namespace is
+ intended to guarantee uniqueness for list owners who require it,
+ while allowing for a less rigorous namespace for experimental and
+ personal use.
+
+ By including the List-Id field, list servers can make it easier for
+ mail clients to provide automated tools for users to perform list
+ functions. The list identifier can serve as a key to make many
+ automated processing tasks easier, and hence more widely available.
+
+1. Introduction
+
+ Internet mailing lists have evolved into fairly sophisticated forums
+ for group communication and collaboration; however, corresponding
+ changes in the underlying infrastructure have lagged behind. Recent
+
+
+
+Chandhok & Wenger Standards Track [Page 1]
+
+RFC 2919 List-Id March 2001
+
+
+ proposals like [RFC2369] have expanded the functionality that the MUA
+ can provide by providing more information in each message sent by the
+ mailing list distribution software.
+
+ Actually implementing such functionality in the MUA depends on the
+ ability to accurately identify messages as belonging to a particular
+ mailing list. The problem then becomes what attribute or property to
+ use to identify a mailing list. The most likely candidate is the
+ submission address of the mailing list itself. Unfortunately, when
+ the list server host, the list processing software, or the submission
+ policy of the list changes the submission address itself can change.
+ This causes great difficulty for automated processing and filtering.
+
+ In order to further automate (and make more accurate) the processing
+ a software agent can do, there needs to be some unique identifier to
+ use as an identifier for the mailing list. This identifier can be
+ simply used for string matching in a filter, or it can be used in
+ more sophisticated systems to uniquely identify messages as belonging
+ to a particular mailing list independent of the particular host
+ delivering the actual messages. This identifier can also act as a
+ key into a database of mailing lists.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119.
+
+2. The List Identifier Syntax
+
+ The list identifier will, in most cases, appear like a host name in a
+ domain of the list owner. In other words, the domain name system is
+ used to delegate namespace authority for list identifiers just as it
+ has been used to distribute that authority for other internet
+ resources.
+
+ Using the domain name system as a basis for the list identifier
+ namespace is intended to leverage an existing authority structure
+ into a new area of application. By using the domain name system to
+ delegate list identifier namespace authority, it becomes instantly
+ clear who has the right to create a particular list identifier, and
+ separates the list identifier from any particular delivery host or
+ mechanism. Only the rights-holder of a domain or subdomain has the
+ authority to create list identifiers in the namespace of that domain.
+ For example, only the rights-holder to the "acm.org" domain has the
+ authority to create list identifiers in "acm.org" domain.
+
+
+
+
+
+
+
+Chandhok & Wenger Standards Track [Page 2]
+
+RFC 2919 List-Id March 2001
+
+
+ While it is perfectly acceptable for a list identifier to be
+ completely independent of the domain name of the host machine
+ servicing the mailing list, the owner of a mailing list MUST NOT
+ generate list identifiers in any domain namespace for which they do
+ not have authority. For example, a mailing list hosting service may
+ choose to assign list identifiers in their own domain based
+ namespace, or they may allow their clients (the list owners) to
+ provide list identifiers in a namespace for which the owner has
+ authority.
+
+ If the owner of the list does not have the authority to create a list
+ identifier in a domain-based namespace, they may create unmanaged
+ list identifiers in the special unmanaged domain "localhost". This
+ would apply to personal users, or users unable to afford domain name
+ registration fees.
+
+ The syntax for a list identifier in ABNF [RFC2234] follows:
+
+ list-id = list-label "." list-id-namespace
+
+ list-label = dot-atom-text
+
+ list-id-namespace = domain-name / unmanaged-list-id-namespace
+
+ unmanaged-list-id-namespace = "localhost"
+
+ domain-name = dot-atom-text
+
+ Where:
+
+ dot-atom-text is defined in [DRUMS]
+
+ "localhost" is a reserved domain name is defined in [RFC2606]
+
+ In addition, a list identifier (list-id) MUST NOT be longer than 255
+ octets in length, for future compatibility. It should be noted that
+ "localhost" is not valid for the domain-name rule.
+
+3. The List-Id Header Field
+
+ This document presents a header field which will provide an
+ identifier for an e-mail distribution list. This header SHOULD be
+ included on all messages distributed by the list (including command
+ responses to individual users), and on other messages where the
+ message clearly applies to this particular distinct list. There MUST
+ be no more than one of each field present in any given message.
+
+
+
+
+
+Chandhok & Wenger Standards Track [Page 3]
+
+RFC 2919 List-Id March 2001
+
+
+ This field MUST only be generated by mailing list software, not end
+ users.
+
+ The contents of the List-Id header mostly consist of angle-bracket
+ ('<', '>') enclosed identifier, with internal whitespace being
+ ignored. MTAs MUST NOT insert whitespace within the brackets, but
+ client applications should treat any such whitespace, that might be
+ inserted by poorly behaved MTAs, as characters to ignore.
+
+ The list header fields are subject to the encoding and character
+ restrictions for mail headers as described in [RFC822].
+
+ The List-Id header MAY optionally include a description by including
+ it as a "phrase" [DRUMS] before the angle-bracketed list identifier.
+ The MUA MAY choose to use this description in its user interface;
+ however, any MUA that intends to make use of the description should
+ be prepared to properly parse and decode any encoded strings or other
+ legal phrase components. For many MUAs the parsing of the List-Id
+ header will simply consist of extracting the list identifier from
+ between the delimiting angle brackets.
+
+ The syntax of the List-Id header follows:
+
+ list-id-header = "List-ID:" [phrase] "<" list-id ">" CRLF
+
+ where phrase and CRLF are as defined in [DRUMS]. Unlike most headers
+ in [RFC822], the List-Id header does not allow free insertion of
+ whitespace and comments around tokens. Any descriptive text must be
+ presented in the optional phrase component of the header.
+
+ Examples:
+
+List-Id: List Header Mailing List <list-header.nisto.com>
+List-Id: <commonspace-users.list-id.within.com>
+List-Id: "Lena's Personal Joke List"
+ <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost>
+List-Id: "An internal CMU List" <0Jks9449.list-id.cmu.edu>
+List-Id: <da39efc25c530ad145d41b86f7420c3b.052000.localhost>
+
+4. Persistence of List Identifiers
+
+ Although the list identifier MAY be changed by the mailing list
+ administrator this is not desirable. (Note that there is no
+ disadvantage to changing the description portion of the List-Id
+ header.) A MUA may not recognize the change to the list identifier
+ because the MUA SHOULD treat a different list identifier as a
+ different list. As such the mailing list administrator SHOULD avoid
+ changing the list identifier even when the host serving the list
+
+
+
+Chandhok & Wenger Standards Track [Page 4]
+
+RFC 2919 List-Id March 2001
+
+
+ changes. On the other hand, transitioning from an informal
+ unmanaged-list-id-namespace to a domain namespace is an acceptable
+ reason to change the list identifier. Also if the focus of the list
+ changes sufficiently the administrator may wish to retire the
+ previous list and its associated identifier to start a new list
+ reflecting the new focus.
+
+5. Uniqueness of List Identifiers
+
+ This proposal seeks to leverage the existing administrative process
+ already in place for domain name allocation. In particular, we
+ exploit the fact that domain name ownership creates a namespace that
+ by definition can be used to create unique identifiers within the
+ domain.
+
+ In addition, there must be a mechanism for identification of mailing
+ lists that are administrated by some entity without administrative
+ access to a domain. In this case, general heuristics can be given to
+ reduce the chance of collision, but it cannot be guaranteed. If a
+ list owner requires a guarantee, they are free to register a domain
+ name under their control.
+
+ It is suggested, but not required, that list identifiers be created
+ under a subdomain of "list-id" within any given domain. This can
+ help to reduce internal conflicts between the administrators of the
+ subdomains of large organizations. For example, list identifiers at
+ "within.com" are generated in the subdomain of "list-id.within.com".
+
+ List-IDs not ending with ".localhost" MUST be globally unique in
+ reference to all other mailing lists.
+
+ List owners wishing to use the special "localhost" namespace for
+ their list identifier SHOULD use the month and year (in the form
+ MMYYYY) that they create the list identifier as a "subdomain" of the
+ "localhost" namespace. In addition, some portion of the list
+ identifier MUST be a randomly generated string. List owners
+ generating such identifiers should refer to [MSGID] for further
+ suggestions on generating a unique identifier, and [RFC1750] for
+ suggestions on generating random numbers. In particular, list
+ identifiers that have a random component SHOULD contain a hex
+ encoding of 128 bits of randomness (resulting in 32 hex characters)
+ as part of the list identifier
+
+ Thus, list identifiers such as
+ <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost> and
+ <da39efc25c530ad145d41b86f7420c3b.051998.localhost> conform to these
+ guidelines, while <lenas-jokes.021999.localhost> and
+
+
+
+
+Chandhok & Wenger Standards Track [Page 5]
+
+RFC 2919 List-Id March 2001
+
+
+ <mylist.localhost> do not. A particular list owner with several
+ lists MAY choose to use the same random number subdomain when
+ generating list identifiers for each of the lists.
+
+ List-IDs ending with ".localhost" are not guaranteed to be globally
+ unique.
+
+6. Operations on List Identifiers
+
+ There is only one operation defined for list identifiers, that of
+ case insensitive equality (See Section 3.4.7., CASE INDEPENDENCE
+ [RFC822]). The sole use of a list identifier is to identify a
+ mailing list, and the sole use of the List-Id header is to mark a
+ particular message as belonging to that list. The comparison
+ operation MUST ignore any part of the List-Id header outside of the
+ angle brackets, the MUA MAY choose to inform the user if the
+ descriptive name of a mailing list changes.
+
+7. Supporting Nested Lists
+
+ A list that is a sublist for another list in a nested mailing list
+ hierarchy MUST NOT modify the List-Id header field; however, this
+ will only be possible when the nested mailing list is aware of the
+ relationship between it and its "parent" mailing lists. If a mailing
+ list processor encounters a List-Id header field from any unexpected
+ source it SHOULD NOT pass it through to the list. This implies that
+ mailing list processors may have to be updated to properly support
+ List-Ids for nested lists.
+
+8. Security Considerations
+
+ There are very few new security concerns generated with this
+ proposal. Message headers are an existing standard, designed to
+ easily accommodate new types. There may be concern with headers
+ being forged, but this problem is inherent in Internet e-mail, not
+ specific to the header described in this document. Further, the
+ implications are relatively harmless.
+
+ As mentioned above, mail list processors SHOULD NOT allow any user-
+ originated List-Id fields to pass through to their lists, lest they
+ confuse the user and have the potential to create security problems.
+
+ On the client side, a forged list identifier may break automated
+ processing. The list identifier (in its current form) SHOULD NOT be
+ used as an indication of the authenticity of the message.
+
+
+
+
+
+
+Chandhok & Wenger Standards Track [Page 6]
+
+RFC 2919 List-Id March 2001
+
+
+9. Acknowledgements
+
+ The numerous participants of the List-Header [LISTHEADER] and
+ ListMom-Talk [LISTMOM] mailing lists contributed much to the
+ formation and structure of this document.
+
+ Grant Neufeld <grant@acm.org> focused much of the early discussion,
+ and thus was essential in the creation of this document.
+
+References
+
+ [LISTHEADER] "List-Header" Mail list. list-header@list.nisto.com
+ <http://www.nisto.com/listspec/mail/>
+ <http://www.nisto.com/listspec/>
+
+ [LISTMOM] "ListMom-Talk" Mail list. listmom-talk@skyweyr.com
+ <http://cgi.skyweyr.com/ListMom.Home>
+
+ [MSGID] J. Zawinski, M. Curtin, "Recommendations for generating
+ Message IDs", Work in Progress.
+
+ [RFC822] Crocker, D., "Standard for the Format of ARPA Internet
+ Text Messages", RFC 822, August 1982.
+
+ [RFC1750] Eastlake, D., Crocker S. and J. Schiller, "Randomness
+ Recommendations for Security", RFC 1750, December 1994.
+
+ [RFC2234] Crocker, D. and P. Overell. "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC2369] Neufeld G. and J. Baer, "The Use of URLs as Meta-Syntax
+ for Core Mail List Commands and their Transport through
+ Message Header Fields", RFC 2369, July 1998.
+
+ [RFC2606] Eastlake, 3rd, D., and S. Panitz. "Reserved Top Level
+ DNS Names", BCP 32, RFC 2606, June 1999.
+
+ [RFC2822] Resnick, P., Editor, "Internet Message Format Standard",
+ STD 11, RFC 2822, March 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+Chandhok & Wenger Standards Track [Page 7]
+
+RFC 2919 List-Id March 2001
+
+
+Authors' Addresses
+
+ Ravinder Chandhok
+ QUALCOMM, Inc.
+ 5775 Morehouse Drive
+ San Diego, CA 92121 USA
+
+ EMail: chandhok@qualcomm.com
+
+
+ Geoffrey Wenger
+ QUALCOMM, Inc.
+ 5775 Morehouse Drive
+ San Diego, CA 92121 USA
+
+ EMail: gwenger@qualcomm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chandhok & Wenger Standards Track [Page 8]
+
+RFC 2919 List-Id March 2001
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chandhok & Wenger Standards Track [Page 9]
+