diff options
Diffstat (limited to 'doc/rfc/rfc2369.txt')
| -rw-r--r-- | doc/rfc/rfc2369.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc2369.txt b/doc/rfc/rfc2369.txt new file mode 100644 index 0000000..77a1f68 --- /dev/null +++ b/doc/rfc/rfc2369.txt @@ -0,0 +1,843 @@ + + + + + + +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:list@host.com?subject=help> (List Instructions) + List-Help: <mailto:list-manager@host.com?body=info> + List-Help: <mailto:list-info@host.com> (Info about the list) + List-Help: <http://www.host.com/list/>, <mailto:list-info@host.com> + List-Help: <ftp://ftp.host.com/list.txt> (FTP), + <mailto:list@host.com?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:list@host.com?subject=unsubscribe> + List-Unsubscribe: (Use this command to get off the list) + <mailto:list-manager@host.com?body=unsubscribe%20list> + List-Unsubscribe: <mailto:list-off@host.com> + + + +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:list-request@host.com?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:list@host.com?subject=subscribe> + List-Subscribe: <mailto:list-request@host.com?subject=subscribe> + List-Subscribe: (Use this command to join the list) + <mailto:list-manager@host.com?body=subscribe%20list> + List-Subscribe: <mailto:list-on@host.com> + List-Subscribe: <http://www.host.com/list.cgi?cmd=sub&lst=list>, + <mailto:list-manager@host.com?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:list@host.com> + List-Post: <mailto:moderator@host.com> (Postings are Moderated) + List-Post: <mailto:moderator@host.com?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:listmom@host.com> (Contact Person for Help) + List-Owner: <mailto:grant@foo.bar> (Grant Neufeld) + List-Owner: <mailto:josh@foo.bar?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:archive@host.com?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 <moore@cs.utk.edu> and Christopher Allen + <ChristopherA@consensus.com> 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 'somelist-request@some.host.com'? 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. list-header@list.nisto.com + <URL:http://www.nisto.com/listspec/mail/> + <URL:http://www.nisto.com/listspec/> + + [6] "ListMom-Talk" Mail list. listmom-talk@skyweyr.com + <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: josh@skyweyr.com + + + Grant Neufeld + Calgary, Alberta + Canada + + EMail: grant@acm.org + 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] + |