[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04                                                
Individual Submission                                  S. Moonesamy, Ed.
Internet-Draft
Obsoletes: 2919 (if approved)                                R. Chandhok
Intended status: Standards Track                               G. Wenger
Expires: August 23, 2012                                  QUALCOMM, Inc.
                                                       February 20, 2012


  List-Id: A Structured Field and Namespace for the Identification of
                             Mailing Lists
                     draft-moonesamy-rfc2919bis-04

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 header fields, it
   has become even more important to provide a unique identifier for a
   mailing list regardless of the particular host that runs the mailing
   list manager at any given time.

   The List-Id header field provides a standard location for such an
   identifier.  In addition, a namespace for mailing 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, mailing list managers can make it
   easier for mail user agents to provide automated tools for users to
   perform mailing list functions.  The mailing list identifier can
   serve as a key for automated processing tasks

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."




Moonesamy, et al.        Expires August 23, 2012                [Page 1]


Internet-Draft                   List-Id                   February 2012


   This Internet-Draft will expire on August 23, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



































Moonesamy, et al.        Expires August 23, 2012                [Page 2]


Internet-Draft                   List-Id                   February 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Note . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  List Identifier Syntax . . . . . . . . . . . . . . . . . . . .  5
   3.  List-Id Header Field . . . . . . . . . . . . . . . . . . . . .  6
   4.  Persistence of List Identifiers  . . . . . . . . . . . . . . .  7
   5.  Uniqueness of List Identifiers . . . . . . . . . . . . . . . .  7
   6.  Operations on List Identifier  . . . . . . . . . . . . . . . .  8
   7.  Supporting Nested Lists  . . . . . . . . . . . . . . . . . . .  8
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     11.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     11.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Subject Tags  . . . . . . . . . . . . . . . . . . . . 10
   Appendix B.  Changes from RFC 2919 . . . . . . . . . . . . . . . . 10
   Appendix C.  Change Log  . . . . . . . . . . . . . . . . . . . . . 11
     C.1.  Changes between between version -03 and version -04  . . . 11
     C.2.  Changes between between version -02 and version -03  . . . 11
     C.3.  Changes between between version -01 and version -02  . . . 11
     C.4.  Changes between between version -00 and version -01  . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

























Moonesamy, et al.        Expires August 23, 2012                [Page 3]


Internet-Draft                   List-Id                   February 2012


1.  Introduction

   Internet mailing lists have evolved into fairly sophisticated forums
   for group communication and collaboration. draft-moonesamy-rfc2369bis
   [ID.moonesamy-rfc2369bis] expands the functionality that the Mail
   User Agent (MUA) can provide by providing more information in each
   message sent by the mailing list manager (MLM).

   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 server
   where the mailing list manager is hosted or the submission policy of
   the list changes the submission address itself can change.  This
   affects automated processing and filtering of messages from mailing
   lists.

   In order to further automate (and make more accurate) the processing
   a software agent can do, RFC 2919 [RFC2919] specified how to generate
   a unique identifier for a 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.

   This document obsoletes RFC 2919 [RFC2919].

1.1.  Terminology

   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 [RFC2119].

1.2.  Syntax Notation

   This specification uses the Augmented Backus-Naur Form (ABNF)
   [RFC5234] notation for the formal definitions of the syntax of list
   header fields.

1.3.  Note

   This Internet-Draft can be discussed on the apps-discuss@ietf.org
   mailing list.  [RFC-Editor: please remove this paragraph]






Moonesamy, et al.        Expires August 23, 2012                [Page 4]


Internet-Draft                   List-Id                   February 2012


2.  List Identifier Syntax

   The List Identifier will, in most cases, appear like a host name in a
   domain of the list owner.  Using the domain name space as a basis for
   the List Identifier namespace, it is intended to leverage an existing
   name space structure to generate a unique identifier.  It also allows
   for the List Identifier to be kept separate from any particular
   delivery host or mechanism.

   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 name space 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 name
   space, 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 mailing list does not have the authority to
   create a List Identifier in a domain-based name space, they may
   create unmanaged List Identifiers in the special unmanaged domain
   "invalid".

   Syntax:

      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 = "invalid"

      domain-name = dot-atom-text

   Where:

      dot-atom-text is defined in [RFC5322]

      "invalid" is a reserved domain name 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
   "invalid" is not valid for the domain-name rule.







Moonesamy, et al.        Expires August 23, 2012                [Page 5]


Internet-Draft                   List-Id                   February 2012


3.  List-Id Header Field

   This document specifies a List-Id header field which will provide an
   identifier for a mailing list.  This header field should be included
   on all messages distributed by the mailing list manager (including
   command responses to individual users), and on other messages where
   the message clearly applies to this particular distinct mailing list.
   There MUST be not be more than one of List-Id header field in any
   given message.

   This field MUST only be generated by mailing list managers, not MUAs.

   The contents of the List-Id header field mostly consist of angle-
   bracket ('<', '>') enclosed identifier, with internal whitespace
   being ignored.  Mailing List Managers MUST NOT insert whitespace
   within the brackets.  Client applications SHOULD treat any such
   whitespace, that might be inserted by poorly behaved mailing list
   managers, as characters to ignore.

   The List-Id header field is subject to the encoding and character
   restrictions for mail headers as described in [RFC5322].

   The List-Id header field MAY optionally include a description by
   including it as a "phrase" [RFC5322] 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 field will simply consist of extracting
   the List Identifier from between the delimiting angle brackets.

   Syntax:

      list-id-header = "List-Id:" [phrase] "<" list-id ">" CRLF

   where phrase and CRLF are as defined in [RFC5322].  Unlike most
   headers fields in RFC 5322 [RFC5322], the List-Id header field 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 field.

   Examples:









Moonesamy, et al.        Expires August 23, 2012                [Page 6]


Internet-Draft                   List-Id                   February 2012


      List-Id:  List Header Mailing List <list-name.example.com>



      List-Id:  <commonspace-users.list-id.example.com>



      List-Id:  "Lena's Personal Joke List" <lenas-
         jokes.da39efc25c530ad145d41b86f7420c3b.021999.invalid>



      List-Id:  <da39efc25c530ad145d41b86f7420c3b.052000.invalid>


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 field.)  A MUA would not recognize the change to the List
   Identifier because a MUA treats 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 mailing
   list changes.  On the other hand, transitioning from an informal
   unmanaged-list-id-namespace to a domain name space is an acceptable
   reason to change the List Identifier.  Also if the focus of the
   mailing list changes sufficiently the administrator may wish to
   retire the previous mailing list and its associated identifier to
   start a new mailing list reflecting the new focus.


5.  Uniqueness of List Identifiers

   This proposal uses a namespace that by definition can be used to
   create unique identifiers within the domain.

   There is a need 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



Moonesamy, et al.        Expires August 23, 2012                [Page 7]


Internet-Draft                   List-Id                   February 2012


   subdomains of large organizations.  For example, List Identifiers at
   "example.com" are generated in the subdomain of "list-
   id.example.com".

   A List Identifier not ending with ".invalid" MUST be globally unique
   in reference to all other mailing lists.  List Identifiers ending
   with ".invalid" are not guaranteed to be globally unique.

   A List Identifier using the special "invalid" namespace SHOULD
   include the month and year (in the form MYYYY), i.e. the List
   Identifier is a "subdomain" of the "invalid" namespace.  In addition,
   some portion of the List Identifier MUST be a randomly generated
   string, e.g. the random [RFC4086] component contains 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.invalid> and
   <da39efc25c530ad145d41b86f7420c3b.051998.invalid> follow these
   guidelines, while <lenas-jokes.021999.invalid> and <mylist.invalid>
   do not.


6.  Operations on List Identifier

   There is only one operation defined for List Identifiers, that of
   case insensitive equality.

   The sole use of a List Identifier is to identify a mailing list, and
   the sole use of the List-Id header field is to mark a particular
   message as belonging to that list.  The comparison operation MUST
   ignore any part of the List-Id header field outside of the angle
   brackets, the MUA may 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.


8.  Security Considerations

   There are very few new security concerns generated with this
   proposal.  Message headers fields are an existing standard, designed



Moonesamy, et al.        Expires August 23, 2012                [Page 8]


Internet-Draft                   List-Id                   February 2012


   to easily accommodate new types.  There may be concern with multiple
   header fields being inserted or headers fields being forged, but
   these are problems inherent in Internet mail, not specific to this
   specification.  If a mailing list manager encounters List-Id header
   fields from any unexpected source it SHOULD NOT pass them through to
   the mailing list.

   As mentioned above, mail list managers should not allow any user-
   originated List-Id header 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.


9.  IANA Considerations

   The List-Id reference in the Permanent Message Header Field Names
   registry should be updated to point to this document.


10.  Acknowledgements

   The numerous participants of the List-Header and ListMom-Talk mailing
   lists contributed much to the formation and structure of this
   document.

   Grant Neufeld focused much of the early discussion, and thus was
   essential in the creation of this document.

   Murray S. Kucherawy provided insightful comments.


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.




Moonesamy, et al.        Expires August 23, 2012                [Page 9]


Internet-Draft                   List-Id                   February 2012


11.2.  Informative References

   [I-D.moonesamy-rfc2369bis]
              Moonesamy, S., Neufeld, G., and J. Baer, "The Use of URIs
              as Meta-Syntax for Core Mail List Commands and their
              Transport through Message Header Fields",
              draft-moonesamy-rfc2369bis-03 (work in progress),
              January 2012.

   [RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
              Names", BCP 32, RFC 2606, June 1999.

   [RFC2919]  Chandhok, R. and G. Wenger, "List-Id: A Structured Field
              and Namespace for the Identification of Mailing Lists",
              RFC 2919, March 2001.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.


Appendix A.  Subject Tags

   A popular feature of some MLMs is the "tagging" of the Subject header
   field by prefixing the header field's contents with the name of the
   mailing list, e.g. "[example]" for a list called "example".  The
   difference between a List Identifier and a subject tag is that while
   a List Identifier is unique, a subject tag is usually the short form
   of a mailing list's name.  Such a namespace is inherently flat,
   unmanaged and thus non-unique.


Appendix B.  Changes from RFC 2919

   This appendix contains a list of changes between this document and
   RFC 2919.

   o  Removed text about the domain name system and domain ownership in
      Section 2

   o  "localhost" replaced with "invalid"

   o  Replaced MTAs with mailing list managers in the sentence: "MTAs
      MUST NOT insert whitespace within the brackets" in Section 3

   o  Case independence in Section 6 changed to case insensitivity for
      ASCII





Moonesamy, et al.        Expires August 23, 2012               [Page 10]


Internet-Draft                   List-Id                   February 2012


   o  Added a paragraph in the appendix about subject tags

   o  Updated references

   o  Editorial changes


Appendix C.  Change Log

   [RFC-Editor: please remove this section]

C.1.  Changes between between version -03 and version -04

   o  Removed List-Sequence header field as it does not fit it

   o  Reverted recommended to MUST NOT in Section 2 as it is a
      requirement in RFC 2919

C.2.  Changes between between version -02 and version -03

   o  Added Ravinder Chandhok as co-author

   o  Added Geoffrey Wenger as co-author

C.3.  Changes between between version -01 and version -02

   o  Added List-Sequence header field

   o  Removed text about about case-insensitive string comparison

   o  Removed recommendation in Section 4 about how the MUA SHOULD treat
      a different List Identifier

C.4.  Changes between between version -00 and version -01

   o  Added informative reference to I-D.moonesamy-rfc2369bis


Authors' Addresses

   S. Moonesamy (editor)
   76, Ylang Ylang Avenue
   Quatre Bornes
   Mauritius

   Email: sm+ietf@elandsys.com





Moonesamy, et al.        Expires August 23, 2012               [Page 11]


Internet-Draft                   List-Id                   February 2012


   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



































Moonesamy, et al.        Expires August 23, 2012               [Page 12]