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:[email protected]?subject=help> (List Instructions)
    List-Help: <mailto:[email protected]?body=info>
    List-Help: <mailto:[email protected]> (Info about the list)
    List-Help: <http://www.host.com/list/>, <mailto:[email protected]>
    List-Help: <ftp://ftp.host.com/list.txt> (FTP),
        <mailto:[email protected]?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:[email protected]?subject=unsubscribe>
    List-Unsubscribe: (Use this command to get off the list)
        <mailto:[email protected]?body=unsubscribe%20list>
    List-Unsubscribe: <mailto:[email protected]>



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:[email protected]?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:[email protected]?subject=subscribe>
    List-Subscribe: <mailto:[email protected]?subject=subscribe>
    List-Subscribe: (Use this command to join the list)
        <mailto:[email protected]?body=subscribe%20list>
    List-Subscribe: <mailto:[email protected]>
    List-Subscribe: <http://www.host.com/list.cgi?cmd=sub&lst=list>,
        <mailto:[email protected]?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:[email protected]>
    List-Post: <mailto:[email protected]> (Postings are Moderated)
    List-Post: <mailto:[email protected]?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:[email protected]> (Contact Person for Help)
    List-Owner: <mailto:[email protected]> (Grant Neufeld)
    List-Owner: <mailto:[email protected]?Subject=list>




Neufeld & Baer              Standards Track                     [Page 5]

RFC 2369                  URLs as Meta-Syntax                  July 1998


3.6. List-Archive

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

  Examples:

    List-Archive: <mailto:[email protected]?subject=index%20list>
    List-Archive: <ftp://ftp.host.com/pub/list/archive/>
    List-Archive: <http://www.host.com/list/archive/> (Web Archive)

4. Supporting Nested Lists

  A list that is a sublist for another 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 fields, and SHOULD insert their own
  versions of those fields.

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

  Dependant on how postings to the 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
  managers. If the intention is that postings should be distributed to
  all members of the primary 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 are an existing standard, designed to
  easily accommodate new types. There may be concern with multiple
  fields being inserted or headers being forged, but these are problems
  inherent in Internet email, not specific to the protocol described in
  this document. Further, the implications are relatively harmless.

  Mail list processors should not allow any user-originated list 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, 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



Neufeld & Baer              Standards Track                     [Page 6]

RFC 2369                  URLs as Meta-Syntax                  July 1998


  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 URLs [RFC1738] apply
  equally to this protocol. Mail client applications should not support
  list header field URLs which could compromise the security of the
  user's system. This includes the "file://" URL type which could
  potentially be used to trigger the execution of a local application
  on some user systems.

6. Acknowledgements

  The numerous participants of the List-Header [5], ListMom-Talk [6],
  List-Managers and MIDA-Mail mailing lists contributed much to the
  formation and structure of this document.

  Keith Moore <[email protected]> and Christopher Allen
  <[email protected]> provided guidance on the standards
  process.






























Neufeld & Baer              Standards Track                     [Page 7]

RFC 2369                  URLs as Meta-Syntax                  July 1998


A. Background Discussion

  This proposal arose from discussions started on the ListMom-Talk
  Discussion List [6]. When the discussion reached a sufficient level,
  a separate list was formed for discussing this proposal, the List
  Headers Mail List [5] for deeper discussion. We have included
  summaries of key issues raised, in order to show some of the
  alternatives examined and reasons for our decisions.

A.1. Multiple header fields vs. a single header field

  Use of a single header field for transporting command meta-syntax was
  rejected for a number of reasons.

  Such a field would require the creation of a new meta-syntax in order
  to describe the list commands (as opposed to the use of the widely
  deployed URL syntax which was chosen for this implementation).  Every
  additional layer of complexity and newness reduces the likelihood of
  actual implementation because it will require additional work to
  support. Also, by using the existing URL syntax, we can profit from
  the end users' knowledge of that syntax and ability to use it even if
  their client applications do not support the list header fields.

  Restricting the transport of meta-syntax to the use of a single
  header field also introduces complications with header field size
  limitations. Most individual commands can easily be described in a
  single line, but describing a multitude of commands can take up many
  lines in the field and runs a greater risk of being modified by an
  existing server on route.

  The client implementation is also easier with multiple fields, since
  each command can be supported and implemented individually,
  completely independent of the others. Thus, some list managers or
  mail clients can choose to implement a subset of the fields based on
  the specific needs of their individual lists.

  Finally, the format described in this document is simple and well
  recognized, which reduces the chances of errors in implementation and
  parsing.

A.2. URLs vs. parameter lists

  URLs are already an established syntax which is flexible, well-
  defined, and in wide spread use. As its definition matures and
  expands, the abilities of the list fields will grow as well, without
  requiring modification of this proposal. URLs are well prepared to
  handle future protocols and developments, and can easily describe the
  different existing access protocols such as mailto, http and ftp.



Neufeld & Baer              Standards Track                     [Page 8]

RFC 2369                  URLs as Meta-Syntax                  July 1998


  Many clients already have functionality for recognizing, parsing, and
  evaluating URLs, either internally or by passing the request to a
  helper application. This makes implementation easier and more
  realistic. As an example, this existing support for URL parsing
  allowed us to add prototype list header functionality to existing
  mail clients (Eudora and Emailer for the Macintosh) without modifying
  their source code.

A.3. Why not just create a standard command language?

  A standard command language, supported by all email list services,
  would go a long way to reducing the problems of list access that
  currently plague existing services. It would reduce the amount of
  learning required by end users and allow for a number of common
  support tools to be developed.

  However, such standardization does pose problems in the areas of
  multi-lingual support and the custom needs of individual mailing
  lists. The development of such a standard is also expected to be met
  with a slow adoption rate by software developers and list service
  providers.

  These points do not preclude the development of such a standard (in
  fact, it would suggest that we should start sooner rather than
  later), but we do need a solution that can be widely supported by the
  current list services.

  We can support most existing list manager command syntaxes without a
  standard command language. By using URLs, we allow alternate access
  methods a standard command language probably wouldn't enable, such as
  web based control.

  Finally, client support for a standard command language is not at all
  clear or necessarily simple to implement. The variety and large
  number of commands existing today would require complicated user
  interfaces which could be confusing and difficult to implement. By
  restricting this proposal to the core functions, the client

  implementation is much simpler, which significantly increases the
  likelihood of implementation (as evidenced by the support already
  announced by a number of client and server application authors).

A.4. Internationalization

  Multilingual support is up to the URL standard. If URLs support it,
  then the List- header fields support it. This is another advantage of
  using URLs as the building blocks for the list header fields.




Neufeld & Baer              Standards Track                     [Page 9]

RFC 2369                  URLs as Meta-Syntax                  July 1998


A.5. Variable Substitution

  Variables would allow the List- header fields to accommodate nearly
  every existing list manager. However, it would immeasurably increase
  the complexity of the entire proposal, and possibly involve
  redefining the URL standard, or force us to use something more
  complicated (and hence more difficult to implement) than URLs to
  describe the command syntax.

  Parameters would either have to be mandatory (i.e. the user agent
  doesn't submit the message if it doesn't know what text to
  substitute) or you need a way to say "if you know this parameter, add
  its text here; otherwise, do this" where "this" is either: (a)
  substitute a constant string, or (b) fail.

  The reason you would want a facility like this is because some list
  server applications insist on having certain parameters like users'
  names, which the user agent might or might not know. e.g. listserv
  insists on having a first name and a last name if you supply either
  one.

  Which could lead to something like the UNIX shell syntax, where
  ${foo-bar} means substitute the value of parameter "foo" if "foo" is
  defined, else substitute the string "bar". Perhaps $foo would mean
  "substitute the value of parameter foo if it is defined, else
  substitute the empty string"

  This all seems far too complicated for the gains involved, especially
  since the use of variables can often be avoided.

  The use of variables in the command syntaxes of list services appears
  to be lessening and does not, in any case, apply to all commands.
  While the unsubscribe and subscribe command header fields may not be
  usable by those systems which require the use of variables, the help
  field will still provide end users with a consistent point of access
  through which they can get support for their use of the list.

A.6. Why not use a specialized MIME part instead of header fields?

  MIME parts were considered, but because most mail clients currently
  either don't support MIME or are not equipped to handle such
  specialized parts - such an implementation would result in problems
  for end users. It is also not as easy for many list servers to
  implement MIME as it is to implement new header fields.

  However, we are looking at the design of a MIME part to more fully
  describe list command syntax, as well as trying to find ways to get
  it supported by the applicable software.



Neufeld & Baer              Standards Track                    [Page 10]

RFC 2369                  URLs as Meta-Syntax                  July 1998


A.7. Why include a Subscribe command?

  Subscribe and Unsubscribe are the key commands needed by almost every
  list. Other commands, such as digest mode, are not as widely
  supported.

  Additionally, users who have unsubscribed (before going on vacation,
  or for whatever other reason) may want to resubscribe to a list. Or,
  a message may be forwarded/bounced from a subscriber to a non-
  subscriber. Or, the user may change addresses and want to subscribe
  from their new address. Having the List-Subscribe field available
  could certainly help in all these cases.

A.8. The Dangers of Header Bloat

  At what point are there just too many header fields?  It really
  varies on a list by list basis. On some lists, the majority of users
  will never be aware of a field unless the client software provides
  some alternative user interface to it (akin to the Reply-To field).
  On others, the users will often see the header fields of messages and
  would be able to recognize the function of the URLs contained within.

  The flexibility afforded by the protocol described in this document
  (in that the header fields may be individually implemented as deemed
  appropriate) provides list administrators with sufficient 'room to
  maneuver' to meet their individual needs.

























Neufeld & Baer              Standards Track                    [Page 11]

RFC 2369                  URLs as Meta-Syntax                  July 1998


B. Client Implementation

B.1. Guidelines

  For 'mailto' URL based commands, mail client applications 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:

    "Do you want to send the unsubscription command 'unsubscribe
    somelist' to '[email protected]'?  Sending the command
    will result in your removal from the associated list."

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

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

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

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





Neufeld & Baer              Standards Track                    [Page 12]

RFC 2369                  URLs as Meta-Syntax                  July 1998


  List", "Contact List Owner" and "Access List Archive". This menu
  could be disabled when not applicable to the current message or
  disappear entirely.

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

B.2.4 Feedback to the User

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

References

  [RFC822] Crocker, D., "Standard for the Format of ARPA
           Internet Text Messages", STD 11, RFC 822, August 1982.

  [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill,
            "Uniform Resource Locators (URL)" RFC 1738, December 1994.

  [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
            Functions", RFC 2142, May 1997.

  [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL
            scheme", RFC 2368, July 1998.

  [5] "List-Header" Mail list. [email protected]
      <URL:http://www.nisto.com/listspec/mail/>
      <URL:http://www.nisto.com/listspec/>

  [6] "ListMom-Talk" Mail list. [email protected]
      <URL:http://cgi.skyweyr.com/ListMom.Home>










Neufeld & Baer              Standards Track                    [Page 13]

RFC 2369                  URLs as Meta-Syntax                  July 1998


Editors' Addresses

  Joshua D. Baer
  Box 273
  4902 Forbes Avenue
  Pittsburgh, PA 15213-3799
  USA

  EMail: [email protected]


  Grant Neufeld
  Calgary, Alberta
  Canada

  EMail: [email protected]
  Web: http://www.nisto.com/


































Neufeld & Baer              Standards Track                    [Page 14]

RFC 2369                  URLs as Meta-Syntax                  July 1998


Full Copyright Statement

  Copyright (C) The Internet Society (1998).  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.
























Neufeld & Baer              Standards Track                    [Page 15]