Internet DRAFT - draft-moonesamy-rfc2369bis
draft-moonesamy-rfc2369bis
Individual Submission S. Moonesamy, Ed.
Internet-Draft G. Neufeld
Obsoletes: 2369 (if approved) J. Baer
Intended status: Standards Track February 20, 2012
Expires: August 23, 2012
The Use of URIs as Meta-Syntax for Core Mail List Commands and their
Transport through Message Header Fields
draft-moonesamy-rfc2369bis-04
Abstract
The mailing list command specification and identification header
fields are a set of structured fields to be added to email messages
sent by email distribution lists. Command header fields typically
contain URIs (usually including "mailto") locating the relevant
information or performing the command directly. The three core
command 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.
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 August 23, 2012.
Copyright Notice
Moonesamy, et al. Expires August 23, 2012 [Page 1]
Internet-Draft URIs for Core Mailing List Commands February 2012
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 3
1.3. Note . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Command Syntax . . . . . . . . . . . . . . . . . . . . . . 4
3. The List Header Fields . . . . . . . . . . . . . . . . . . . . 5
3.1. List-Help . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. List-Unsubscribe . . . . . . . . . . . . . . . . . . . . . 6
3.3. List-Subscribe . . . . . . . . . . . . . . . . . . . . . . 7
3.4. List-Post . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. List-Owner . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. List-Archive . . . . . . . . . . . . . . . . . . . . . . . 9
4. Supporting Nested Lists . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Implementation . . . . . . . . . . . . . . . . . . . 12
Appendix B. Changes from RFC 2369 . . . . . . . . . . . . . . . . 12
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 12
C.1. Changes between between version -03 and version -04 . . . 12
C.2. Changes between between version -02 and version -03 . . . 13
C.3. Changes between between version -01 and version -02 . . . 13
C.4. Changes between between version -00 and version -01 . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Moonesamy, et al. Expires August 23, 2012 [Page 2]
Internet-Draft URIs for Core Mailing List Commands February 2012
1. Introduction
RFC 2369 [RFC2369] defined additional header fields to be added to
email messages sent by mailing list managers (MLMs). The significant
change in this document is the use of Uniform Resource Identifier
(URI) [RFC3986], instead of Uniform Resource Locator (URL), allowing
an implementation to parse the common components of a URI reference
without knowing the scheme-specific requirements of every possible
identifier. The content of each new header field is typically a URI
- 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. 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. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF)
[RFC5234] notation for the formal definitions of the syntax of list
header fields.
Moonesamy, et al. Expires August 23, 2012 [Page 3]
Internet-Draft URIs for Core Mailing List Commands February 2012
1.3. 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
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 scheme that it supports, or knows how to access by a
separate application. With this mechanism, schemes like http may be
specified while still providing the basic "mailto" support for those
clients who do not have access to non-mail scheme. 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 schemes
(such as ftp and http) although it is expected that the "mailto"
scheme [RFC6068] will be the focus of most use of the list header
fields. Use of the schemes should be considered in light of those
users who do not have access to the specified mechanism.
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
Moonesamy, et al. Expires August 23, 2012 [Page 4]
Internet-Draft URIs for Core Mailing List Commands February 2012
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:
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.
3.1. List-Help
The List-Help header field 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.
Syntax:
uri-list = "<" URI ">" *("," [ FWS ] "<" URI ">")
; whereas <URI> is defined in RFC 3986 and <FWS> and
Moonesamy, et al. Expires August 23, 2012 [Page 5]
Internet-Draft URIs for Core Mailing List Commands February 2012
; <CFWS> in RFC 5322
; CRLF is the carriage return/line feed pair
list-help = "List-Help:" [ CFWS ] uri-list [ CFWS ] CRLF
Examples:
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 to directly
unsubscribe the user (removing them from the list).
Syntax:
list-unsubscribe = "List-Unsubscribe:" uri-list [ CFWS ] CRLF
Examples:
List-Unsubscribe:
<mailto:list-request@example.com?subject=unsubscribe>
Moonesamy, et al. Expires August 23, 2012 [Page 6]
Internet-Draft URIs for Core Mailing List Commands February 2012
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>
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 to directly
subscribe the user (request addition to the list).
Syntax:
list-subscribe = "List-Subscribe:" uri-list [ CFWS ] CRLF
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>
Moonesamy, et al. Expires August 23, 2012 [Page 7]
Internet-Draft URIs for Core Mailing List Commands February 2012
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".
Syntax:
list-post = "List-Post:" uri-list/"NO" [ CFWS ] CRLF
Examples:
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.
Syntax:
list-owner = "List-Owner:" uri-list [ CFWS ] CRLF
Examples:
Moonesamy, et al. Expires August 23, 2012 [Page 8]
Internet-Draft URIs for Core Mailing List Commands February 2012
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.
Syntax:
list-archive = "List-Archive:" uri-list [ CFWS ] CRLF
Examples:
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.
Moonesamy, et al. Expires August 23, 2012 [Page 9]
Internet-Draft URIs for Core Mailing List Commands February 2012
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 header field 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.
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.
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
Moonesamy, et al. Expires August 23, 2012 [Page 10]
Internet-Draft URIs for Core Mailing List Commands February 2012
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
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.
We would like to thank the the following people for their
contributions: Mykyta Yevstifeye, Murray S. Kucherawy and John
Levine.
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.
[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.
[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.
Moonesamy, et al. Expires August 23, 2012 [Page 11]
Internet-Draft URIs for Core Mailing List Commands February 2012
[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.
[RFC5064] Duerst, M., "The Archived-At Message Header Field",
RFC 5064, December 2007.
Appendix A. Implementation
RFC 2369 contains a discussion about the design decisions for List-
header fields.
Appendix B. 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 reference to RFC 5064
o Editorial changes
o Removed Background Discussion
Appendix C. Change Log
[RFC-Editor: please remove this section]
C.1. Changes between between version -03 and version -04
o Removed sections about List-ID and List-Sequence as they are not
URIs
Moonesamy, et al. Expires August 23, 2012 [Page 12]
Internet-Draft URIs for Core Mailing List Commands February 2012
C.2. Changes between between version -02 and version -03
o Added Grant Neufeld as co-author
o Added Joshua Baer as co-author
o Move List-Sequence header field definition to I-D.moonesamy-
rfc2919bis
C.3. Changes between between version -01 and version -02
o Added ABNF and reference to RFC 5234
o Removed text about postmaster in List-Owner Section
o Removed User Interface guidelines from Appendix B
o Removed SHOULD include a "mailto" based command in Section 3
o Modified the text to first paragraph of Section 3.1
C.4. Changes between between version -00 and version -01
o Added List-Sequence header field
o Added informative reference to I-D.moonesamy-rfc2919bis
Authors' Addresses
S. Moonesamy (editor)
76, Ylang Ylang Avenue
Quatre Bornes
Mauritius
Email: sm+ietf@elandsys.com
Grant Neufeld
Calgary, Alberta
Canada
Email: grant@grantneufeld.ca
Moonesamy, et al. Expires August 23, 2012 [Page 13]
Internet-Draft URIs for Core Mailing List Commands February 2012
Joshua Baer
Austin, Texas
USA
Email: ietf@joshuabaer.com
URI: http://joshuabaer.com/
Moonesamy, et al. Expires August 23, 2012 [Page 14]
