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

Versions: 00 01 02 03 04                                                
Individual Submission                                  S. Moonesamy, Ed.
Internet-Draft                                         December 11, 2011
Obsoletes: 2369 (if approved)
Intended status: Standards Track
Expires: June 13, 2012


  The Use of URIs as Meta-Syntax for Core Mail List Commands and their
                Transport through Message Header Fields
                     draft-moonesamy-rfc2369bis-00

Abstract

   The mailing list command specification header fields are a set of
   structured fields to be added to email messages sent by email
   distribution lists.  Each header field typically contains a URI
   (usually mailto) locating the relevant information or performing the
   command directly.  The three core header fields described in this
   document are List-Help, List-Subscribe, and List-Unsubscribe.

   There are three other header fields described here which, although
   not as widely applicable, will have utility for a sufficient number
   of mailing lists to justify their formalization here.  These are
   List-Post, List-Owner and List-Archive.

   By including these header fields, mailing list managers can make it
   possible for mail user agents to provide automated tools for users to
   perform list functions.  This could take the form of a menu item,
   push button, or other user interface element.  The intent is to
   simplify the user experience, providing a common interface to the
   often cryptic and varied mailing list manager commands.

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."

   This Internet-Draft will expire on June 13, 2012.



Moonesamy                 Expires June 13, 2012                 [Page 1]


Internet-Draft     URIs for Core Mailing List Commands     December 2011


Copyright Notice

   Copyright (c) 2011 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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

























Moonesamy                 Expires June 13, 2012                 [Page 2]


Internet-Draft     URIs for Core Mailing List Commands     December 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Note . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  The Command Syntax . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The List Header Fields . . . . . . . . . . . . . . . . . . . .  6
     3.1.  List-Help  . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  List-Unsubscribe . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  List-Subscribe . . . . . . . . . . . . . . . . . . . . . .  8
     3.4.  List-Post  . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.5.  List-Owner . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.6.  List-Archive . . . . . . . . . . . . . . . . . . . . . . .  9
     3.7.  List-Id  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.  Supporting Nested Lists  . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Appendix A.  Appendix  . . . . . . . . . . . . . . . . . . . . . . 12
     A.1.  Client Implementation  . . . . . . . . . . . . . . . . . . 12
       A.1.1.  Guidelines . . . . . . . . . . . . . . . . . . . . . . 12
       A.1.2.  Implementation Options . . . . . . . . . . . . . . . . 13
         A.1.2.1.  Key combinations and command lines . . . . . . . . 13
         A.1.2.2.  Menu items . . . . . . . . . . . . . . . . . . . . 13
         A.1.2.3.  Push Buttons and Pallettes . . . . . . . . . . . . 13
         A.1.2.4.  Feedback to the User . . . . . . . . . . . . . . . 14
     A.2.  Changes from RFC 2369  . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14




















Moonesamy                 Expires June 13, 2012                 [Page 3]


Internet-Draft     URIs for Core Mailing List Commands     December 2011


1.  Introduction

   RFC 2369 [RFC2369] defined additional header fields to be added to
   email messages sent by mailing list managers (MLMs).  The content of
   each new header field is typically a URI [RFC3986] - usually mailto
   [RFC6068] - which identifies the relevant information or performs the
   command directly.

   These headers fields are optional.  Significant functionality and
   convenience can be gained by including them.  The List-Help header
   field provides an access point to detailed user support information,
   and accommodates almost all existing mailing list managers command
   sets.  The List-Subscribe and List-Unsubscribe header fields provide
   access to two functions commonly requested by mailing list
   subscribers.

   The description of command syntax provided by the header fields can
   be used by mail user agents (MUAs) to provide simplified and
   consistent user access to mailing list functions.  This could take
   the form of menu items, push buttons, or other user interface
   elements.  The intent is to simplify the user experience, providing a
   common interface to the often cryptic and varied mailing list manager
   commands.

   Consideration has been given to avoiding the creation of too many
   header fields, while at the same time avoiding the overloading of
   individual header fields and keeping the syntax clear and simple.

   The use of these header fields does not remove the requirement to
   support the -Request command address for mailing lists [RFC2142].

   This document obsoletes RFC 2369 [RFC2369].

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.  Note

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


2.  The Command Syntax

   The list header fields are subject to the encoding and character



Moonesamy                 Expires June 13, 2012                 [Page 4]


Internet-Draft     URIs for Core Mailing List Commands     December 2011


   restrictions for mail headers fields as described in [RFC5322].

   The contents of the list header fields mostly consist of angle-
   bracket ('<', '>') enclosed URIs [RFC3986], with internal whitespace
   being ignored. mailing list managers MUST NOT insert whitespace
   within the brackets.  Client applications SHOULD treat any
   whitespace, that might be inserted by poorly behaved mailing list
   managers, as characters to ignore.

   A list of multiple, alternate, URIs MAY be specified by a comma-
   separated list of angle-bracket enclosed URIs.  The URIs have order
   of preference from left to right.  The client application should use
   the left most protocol that it supports, or knows how to access by a
   separate application.  By this mechanism, protocols like http may be
   specified while still providing the basic mailto support for those
   clients who do not have access to non-mail protocols.  The client
   should only use one of the available URIs for a command, using
   another only if the first one used failed.

   The use of URIs allows for the use of the syntax with existing URI
   supporting applications.  As the standard for URIs is extended, the
   list header fields will gain the benefit of those extensions.
   Additionally, the use of URIs provides access to multiple transport
   protocols (such as ftp and http) although it is expected that the
   "mailto" protocol [RFC6068] will be the focus of most use of the list
   header fields.  Use of non-mailto protocols should be considered in
   light of those users who do not have access to the specified
   mechanism (those who only have email - with no web access).

   Command syntaxes requiring variable fields to be set by the client
   (such as including the user's email address within a command) are not
   supported by this implementation.  However, mailing list managers
   using such syntaxes should still take advantage of the List-Help
   field to provide the user with detailed instructions as needed or -
   perhaps more usefully - provide access to some form of structured
   command interface such as an HTML-based form.

   The additional complications of supporting variable fields within the
   command syntax was determined to be too difficult to support by this
   protocol and would compromise the likelihood of implementation by
   software authors.

   To allow for future extension, it is recommended that client
   applications follow the guidelines below for handling the contents of
   the header fields described in this document:






Moonesamy                 Expires June 13, 2012                 [Page 5]


Internet-Draft     URIs for Core Mailing List Commands     December 2011


   1.  Except where noted for specific header fields, if the content of
       the header field (following any leading whitespace, including
       comments) begins with any character other than the opening angle
       bracket '<', the header field SHOULD be ignored.

   2.  Any characters following an angle bracket enclosed URI SHOULD be
       ignored, unless a comma is the first non-whitespace/comment
       character after the closing angle bracket.

   3.  If a sub-item (comma-separated item) within the field is not an
       angle-bracket enclosed URI, the remainder of the field (the
       current, and all subsequent, sub-items) SHOULD be ignored.


3.  The List Header Fields

   This document presents header fields which will provide the command
   syntax description for the 'core' and key secondary functions of most
   mailing list managers.  The header fields implemented on a given
   mailing list 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 one distinct mailing
   list.  There MUST be no more than one of each header field present in
   any given message.

   These header fields MUST only be generated by mailing list managers,
   not by MUAs.  Mailing list managers generating the list header fields
   SHOULD include a mailto based command, in addition to any other
   protocols used, in order to support users who do not have access to
   non-mail-based protocols.

3.1.  List-Help

   The List-Help header field is the most important of the header fields
   described in this document.  It is acceptable for a mailing list
   manager to include only this header field, since by definition it can
   direct the user to complete instructions for all other commands.
   Typically, the URI specified would request the help file, perhaps
   incorporating an HTML form for list commands, for the list, and
   alternatively provide access to an instructive website.

   Examples:









Moonesamy                 Expires June 13, 2012                 [Page 6]


Internet-Draft     URIs for Core Mailing List Commands     December 2011


      List-Help:  <mailto:list-request@example.com?subject=help> (List
         Instructions)



      List-Help:  <mailto:list-request@example.com?body=info>



      List-Help:  <mailto:list-info@example.com> (Info about the list)



      List-Help:  <http://www.example.com/list/>,
         <mailto:list-info@example.com>



      List-Help:  <ftp://ftp.example.com/list.txt> (FTP),
         <mailto:list-request@example.com?subject=help>

3.2.  List-Unsubscribe

   The List-Unsubscribe header field describes the command (preferably
   using mail) to directly unsubscribe the user (removing them from the
   list).

   Examples:



      List-Unsubscribe:
         <mailto:list-request@example.com?subject=unsubscribe>



      List-Unsubscribe:  (Use this command to get off the list)
         <mailto:list-request@example.com?body=unsubscribe%20list>



      List-Unsubscribe:  <mailto:list-remove@example.com>









Moonesamy                 Expires June 13, 2012                 [Page 7]


Internet-Draft     URIs for Core Mailing List Commands     December 2011


      List-Unsubscribe:
         <http://www.example.com/list.cgi?cmd=unsub&lst=list>,
         <mailto:list-request@example.com?subject=unsubscribe>

3.3.  List-Subscribe

   The List-Subscribe header field describes the command (preferably
   using mail) to directly subscribe the user (request addition to the
   list).

   Examples:



      List-Subscribe:
         <mailto:list-request@example.com?subject=subscribe>



      List-Subscribe:  (Use this command to join the list)
         <mailto:list-request@example.com?body=subscribe%20list>



      List-Subscribe:  <mailto:list-add@example.com>



      List-Subscribe:
         <http://www.example.com/list.cgi?cmd=sub&lst=list>,
         <mailto:list-request@example.com?body=subscribe%20list>

3.4.  List-Post

   The List-Post header field describes the method for posting to the
   mailing list.  This is typically the email address of the mailing
   list.  It can also be the email address of a moderator, or
   potentially some other form of submission.  For the special case of a
   mailing list that does not allow posting (e.g., an announcements
   list), the List-Post field may contain the special value "NO".

   Examples:









Moonesamy                 Expires June 13, 2012                 [Page 8]


Internet-Draft     URIs for Core Mailing List Commands     December 2011


      List-Post:  <mailto:list@example.com>



      List-Post:  <mailto:list-moderator@example.com> (Postings are
         Moderated)



      List-Post:
         <mailto:list-moderator@example.com?subject=list%20posting>



      List-Post:  NO (posting not allowed on this list)

3.5.  List-Owner

   The List-Owner header field identifies the path to contact a human
   administrator for the mailing list.  The URI may contain the email
   address of an administrator for the mailing list, the mail system
   administrator, or any other person who can handle user contact for
   the mailing list.  There is no need to specify List-Owner if it is
   the same person as the mail system administrator (postmaster).

   Examples:



      List-Owner:  <mailto:list-admin@example.com> (Contact Person for
         Help)



      List-Owner:  <mailto:grant@example.com> (Grant Neufeld)



      List-Owner:  <mailto:josh@example.com?Subject=list>

3.6.  List-Archive

   The List-Archive header field describes how to access archives for
   the mailing list.

   Examples:





Moonesamy                 Expires June 13, 2012                 [Page 9]


Internet-Draft     URIs for Core Mailing List Commands     December 2011




      List-Archive:
         <mailto:list-request@example.com?subject=index%20list>



      List-Archive:  <ftp://ftp.example.com/pub/list/archive/>



      List-Archive:  <http://www.example.com/list/archive/> (Web
         Archive)



      List-Archive:  <imap://archive.example.com/list>

   The Archive-At header field [RFC5064] provides a pointer to an
   archived form of a single message.

3.7.  List-Id

   The List-Id header field provides an identifier for an e-mail
   distribution list [RFC2919].


4.  Supporting Nested Lists

   A mailing list that is a sublist for another mailing list in a nested
   mailing list hierarchy will need to modify some of the List- header
   fields, while leaving others as the parent list set them.

   Sublists SHOULD remove the parent list's List-Help, List-Subscribe,
   List-Unsubscribe and List-Owner header fields, and SHOULD insert
   their own versions of those header fields.

   If the sublist provides its own archive, it SHOULD replace the List-
   Archive with its own.  Otherwise, it MUST leave the List-Archive
   header field untouched.

   Dependant on how postings to the mailing list are handled, the
   sublist MAY replace the List-Post field.  The appropriateness of
   whether to replace List-Post is left to the determination of the
   individual list administrators.  If the intention is that postings
   should be distributed to all members of the primary mailing list,
   List-Post should not be changed by a sublist in such a way that
   postings will be distributed only to members of the sublist.



Moonesamy                 Expires June 13, 2012                [Page 10]


Internet-Draft     URIs for Core Mailing List Commands     December 2011


5.  Security Considerations

   There are very few new security concerns generated with this
   proposal.  Message headers fields are an existing standard, designed
   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.  Furthermore, the implications are relatively
   harmless.

   Mailing list managers should not allow any user-originated list
   header fields to pass through to the mailing lists, lest they confuse
   the user and have the potential to create security problems.

   On the client side, there may be some concern with posts or commands
   being sent in error.  It is required that the user have a chance to
   confirm any action before it is executed.  In the case of mailto, it
   may be appropriate to create the correctly formatted message without
   sending it, allowing the user to see exactly what is happening and
   giving the user the opportunity to approve or discard the message
   before it is sent.

   All security considerations for the use of URIs [RFC3986] apply
   equally to this specification.  Mail User Agents should not process
   list header field URIs which could compromise the security of the
   user's system.  This includes the "file://" URI type which could
   potentially be used to trigger the execution of a local application
   on some user systems.


6.  IANA Considerations

   The List-Archive, List-Help, List-Owner, List-Post, List-Subscribe,
   and List-Unsubscribe references in the Permanent Message Header Field
   Names registry should be updated to point to this document.


7.  Acknowledgements

   Most of the text in this document was copied from RFC 2369, authored
   by Joshua D. Baer and Grant Neufeld.

   The numerous participants of the List-Header, ListMom-Talk, List-
   Managers and MIDA-Mail mailing lists contributed much to the
   formation and structure of RFC 2369 with Keith Moore and Christopher
   Allen providing guidance on the standards process.





Moonesamy                 Expires June 13, 2012                [Page 11]


Internet-Draft     URIs for Core Mailing List Commands     December 2011


8.  References

8.1.  Normative References

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

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

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

   [RFC6068]  Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
              URI Scheme", RFC 6068, October 2010.

8.2.  Informative References

   [RFC2142]  Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
              FUNCTIONS", RFC 2142, May 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.

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

   [RFC5064]  Duerst, M., "The Archived-At Message Header Field",
              RFC 5064, December 2007.


Appendix A.  Appendix

A.1.  Client Implementation

A.1.1.  Guidelines

   For 'mailto' URI based commands, Mail User Agents may choose to
   provide specialized feedback (such as presenting a dialog or alert),
   instead of the actual command email message, asking for command
   confirmation from the user.  The feedback should identify the message
   destination and command within a more descriptive explanation.  For
   example:





Moonesamy                 Expires June 13, 2012                [Page 12]


Internet-Draft     URIs for Core Mailing List Commands     December 2011


      "Do you want to send the unsubscription command 'unsubscribe
      somelist' to 'somelist-request@some.example.com'?  Sending the
      command will result in your removal from the associated list."

   If the user has multiple email addresses supported by the Mail User
   Agent, the MUA should prompt the user for which email address to use
   when subscribing or performing some other action where the email
   address to use cannot be specifically determined.  When unsubscribing
   or such, the email address that is subscribed should be used, unless
   that is not known by the application and cannot be determined from
   the message headers.

A.1.2.  Implementation Options

   The following implementation possibilities are suggested here to give
   some idea as to why these new header fields will be useful, and how
   they could be supported.

   In most cases, it may be helpful to disable the interface for the
   commands when not applicable to the currently selected message.

A.1.2.1.  Key combinations and command lines

   On text based systems which utilize command lines or key
   combinations, each field could be implemented as a separate command.
   Thus one combination would subscribe the user, another would
   unsubscribe, a third request help, etc.  The commands would only be
   available on messages containing the list header fields.

A.1.2.2.  Menu items

   On graphical systems which have menus, these commands could take the
   form of a menu or sub-menu of items.  For example, a "Lists" menu
   might appear when viewing messages containing the header fields, with
   items named "Subscribe", "Unsubscribe", "Get Help", "Post Message to
   List", "Contact List Owner" and "Access List Archive".  This menu
   could be disabled when not applicable to the current message or
   disappear entirely.

A.1.2.3.  Push Buttons and Pallettes

   On graphical window systems, buttons could be placed in the window of
   the message, a toolbar, or in a floating pallette of their own.  Each
   button could correspond to a command, with names "Subscribe",
   "Unsubscribe", "Get Help", "Post to List", "List Owner" and
   "Archive".  These buttons or pallettes could be disabled when not
   applicable to the current message or disappear entirely.




Moonesamy                 Expires June 13, 2012                [Page 13]


Internet-Draft     URIs for Core Mailing List Commands     December 2011


A.1.2.4.  Feedback to the User

   If using a dialog interface (or other feedback element) the mail user
   agent must include an option for the user to review (and possibly
   modify) the message before it is sent.  It may also be useful for
   mail user agents to provide a link to more detailed context-
   sensitive assistance about mailing list access in general.

A.2.  Changes from RFC 2369

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

   o  URL changed to URI

   o  Replaced MTAs with mailing list managers in the sentence: "MTAs
      generating the header fields SHOULD".

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

   o  In Section 2, client application SHOULD ignore whitespace within
      brackets

   o  Updated references

   o  Added informative references to RFC 2919 and RFC 5064

   o  Editorial changes

   o  Removed Background Discussion


Author's Address

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

   Email: sm+ietf@elandsys.com










Moonesamy                 Expires June 13, 2012                [Page 14]