rfc2369.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                      G. Neufeld
Request for Comments: 2369                                      Nisto
Category: Standards Track                                     J. Baer
                                                 SkyWeyr Technologies
                                                            July 1998


       The Use of URLs as Meta-Syntax for Core Mail List Commands
           and their Transport through Message Header Fields

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 (1998).  All Rights Reserved.

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 field typically contains a URL (usually
   mailto [RFC2368]) 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, list servers can make it possible
   for mail clients 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.

   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.





Neufeld & Baer              Standards Track                     [Page 1]

RFC 2369                  URLs as Meta-Syntax                  July 1998


1. Introduction

   This is a proposal for additional header fields to be added to email
   messages sent by email distribution lists. The content of each new
   field is typically a URL - usually mailto [RFC2368] - which locates
   the relevant information or performs the command directly. MTAs
   generating the header fields SHOULD usually 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.

   Implementing these fields will be optional. Significant functionality
   and convenience can be gained by including them, however. Many list
   managers, especially as the proposal first gains acceptance, MAY
   choose to implement only one or two of the fields.  The List-Help
   field is the most useful individual field since it provides an access
   point to detailed user support information, and accommodates almost
   all existing list managers command sets. The List-Subscribe and
   List-Unsubscribe fields are also very useful, but cannot describe
   some list manager syntaxes at this time (those which require variable
   substitution). See appendix A.5 for an explanation.

   The description of command syntax provided by the fields can be used
   by mail client applications to provide simplified and consistent user
   access to email distribution 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
   fields, while at the same time avoiding the overloading of individual
   fields and keeping the syntax clear and simple.

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

2. The Command Syntax

   The list header fields are subject to the encoding and character
   restrictions for mail headers as described in [RFC822]. Additionally,
   the URL content is further restricted to the set of URL safe
   characters [RFC1738].

   The contents of the list header fields mostly consist of angle-
   bracket ('<', '>') enclosed URLs, with internal whitespace being
   ignored. MTAs MUST NOT insert whitespace within the brackets, but
   client applications should treat any whitespace, that might be
   inserted by poorly behaved MTAs, as characters to ignore.



Neufeld & Baer              Standards Track                     [Page 2]

RFC 2369                  URLs as Meta-Syntax                  July 1998


   A list of multiple, alternate, URLs MAY be specified by a comma-
   separated list of angle-bracket enclosed URLs. The URLs 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 URLs for a command, using
   another only if the first one used failed.

   The use of URLs allows for the use of the syntax with existing URL
   supporting applications. As the standard for URLs is extended, the
   list header fields will gain the benefit of those extensions.
   Additionally, the use of URLs provides access to multiple transport
   protocols (such as ftp and http) although it is expected that the
   "mailto" protocol [RFC2368] 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, systems 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, client applications MUST follow the
   following guidelines for handling the contents of the header fields
   described in this document:

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

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






Neufeld & Baer              Standards Track                     [Page 3]

RFC 2369                  URLs as Meta-Syntax                  July 1998


   3) If a sub-item (comma-separated item) within the field is not an
      angle-bracket enclosed URL, 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 email distribution lists. The fields implemented
      on a given 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
      list. There MUST be no more than one of each field present in any
      given message.

      These fields MUST only be generated by mailing lists, not end
      users.

3.1. List-Help

      The List-Help field is the most important of the header fields
      described in this document. It would be acceptable for a list
      manager to include only this field, since by definition it SHOULD
      direct the user to complete instructions for all other commands.
      Typically, the URL 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:

     List-Help: <mailto:[e-mail]?subject=help> (List Instructions)
     List-Help: <mailto:[e-mail]?body=info>
     List-Help: <mailto:[e-mail]> (Info about the list)
     List-Help: <http://www.host.com/list/>, <mailto:[e-mail]>
     List-Help: <ftp://ftp.host.com/list.txt> (FTP),
         <mailto:[e-mail]?subject=help>

3.2. List-Unsubscribe

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

   Examples:

     List-Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
     List-Unsubscribe: (Use this command to get off the list)
         <mailto:[e-mail]?body=unsubscribe%20list>
     List-Unsubscribe: <mailto:[e-mail]>



Neufeld & Baer              Standards Track                     [Page 4]

RFC 2369                  URLs as Meta-Syntax                  July 1998


     List-Unsubscribe: <http://www.host.com/list.cgi?cmd=unsub&lst=list>,
         <mailto:[e-mail]?subject=unsubscribe>

3.3. List-Subscribe

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

   Examples:

     List-Subscribe: <mailto:[e-mail]?subject=subscribe>
     List-Subscribe: <mailto:[e-mail]?subject=subscribe>
     List-Subscribe: (Use this command to join the list)
         <mailto:[e-mail]?body=subscribe%20list>
     List-Subscribe: <mailto:[e-mail]>
     List-Subscribe: <http://www.host.com/list.cgi?cmd=sub&lst=list>,
         <mailto:[e-mail]?body=subscribe%20list>

3.4. List-Post

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

   Examples:

     List-Post: <mailto:[e-mail]>
     List-Post: <mailto:[e-mail]> (Postings are Moderated)
     List-Post: <mailto:[e-mail]?subject=list%20posting>
     List-Post: NO (posting not allowed on this list)

3.5. List-Owner

   The List-Owner field identifies the path to contact a human
   administrator for the list. The URL MAY contain the address of a
   administrator for the list, the mail system administrator, or any
   other person who can handle user contact for the 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:[e-mail]> (Contact Person for Help)
     List-Owner: <mailto:[e-mail]> (Grant Neufeld)
     List-Owner: <mailto:[e-mail]?Subject=list>




Neufeld & Baer              Standards Track                     [Page 5]