< draft-baer-listspec-00.txt   draft-baer-listspec-01.txt >
INTERNET-DRAFT Grant Neufeld INTERNET-DRAFT Grant Neufeld
draft-baer-listspec-00.txt independent developer draft-baer-listspec-01.txt independent developer
Expires August 27, 1997 Joshua D. Baer Expires February 18, 1998 Joshua D. Baer
SkyWeyr Technologies SkyWeyr Technologies
March 22, 1997 August 18, 1997
The Use of URLs as Meta-Syntax for Core Mail List Commands The Use of URLs as Meta-Syntax for Core Mail List Commands
and their Transport through Message Header Fields and their Transport through Message Header Fields
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
To learn the current status of any Internet-Draft, please check To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet- the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa), Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
The mailing list command specification header fields are a simple set The mailing list command specification header fields are a simple set
of fields to be added to email messages sent by email distribution of fields to be added to email messages sent by email distribution
lists. Each field contains a URL (usually mailto or http) locating lists. Each field contains a URL (usually mailto) locating the
the relevant information or performing the command directly. The relevant information or performing the command directly. The three
three core header fields described in this document are List-Help, core header fields described in this document are List-Help,
List-Subscribe, and List-Unsubscribe. 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, mail clients can provide automated By including these header fields, mail clients can provide automated
tools for performing these functions. This could take the form of a tools for performing these functions. This could take the form of a
menu item, push button, or other user interface element. The intent menu item, push button, or other user interface element. The intent
is to simplify the user experience, providing a common interface to is to simplify the user experience, providing a common interface to
the often cryptic and varied mailing list manager commands. the often cryptic and varied mailing list manager commands.
1. Introduction 1. Introduction
This is a proposal for additional header fields to be added to email This is a proposal for additional header fields to be added to email
messages sent by email distribution lists. The content of each new messages sent by email distribution lists. The content of each new
header is a URL (usually mailto or http) locating the relevant field is a URL - usually mailto or http, with mailto generally
information or performing the command directly. The three core taking precedence - locating the relevant information or performing
headers are List-Help, List-Subscribe, and List-Unsubscribe. the command directly.
Implementing these headers will be optional. Significant Implementing these fields will be optional. Significant
functionality and convenience can be gained by including them, functionality and convenience can be gained by including them,
however. Many list managers, especially as the proposal first gains however. Many list managers, especially as the proposal first gains
acceptance, may only choose to implement one or two of the headers. acceptance, may only choose to implement one or two of the fields.
The List-Help header is the most useful individual header since it The List-Help field is the most useful individual field since it
provides an access point to detailed user support information, and provides an access point to detailed user support information, and
accommodates almost all existing list managers command sets. The accommodates almost all existing list managers command sets. The
List-Subscribe and List-Unsubscribe headers are also very useful, but List-Subscribe and List-Unsubscribe fields are also very useful, but
cannot describe some list manager syntaxes at this time (those which cannot describe some list manager syntaxes at this time (those which
require variable substitution). See the appendix for an explanation. require variable substitution). See appendix A.5 for an explanation.
The description of command syntax provided by the headers can be used The description of command syntax provided by the fields can be used
by mail client applications to provide simplified and consistent user by mail client applications to provide simplified and consistent user
access to email distribution list functions. This could take the access to email distribution list functions. This could take the
form of menu items, push buttons, or other user interface elements. form of menu items, push buttons, or other user interface elements.
The intent is to simplify the user experience, providing a common The intent is to simplify the user experience, providing a common
interface to the often cryptic and varied mailing list manager interface to the often cryptic and varied mailing list manager
commands. commands.
Consideration has been given to avoiding the creation of too many Consideration has been given to avoiding the creation of too many
headers, while at the same time avoiding the overloading of fields, while at the same time avoiding the overloading of
individual headers and keeping the syntax clear and simple. individual fields and keeping the syntax clear and simple.
2. The Command Syntax 2. The Command Syntax
The contents of the list headers consist of angle-bracket ('<', '>') The contents of the list header fields consist of angle-bracket
enclosed URLs, with internal whitespace being ignored. ('<', '>') enclosed URLs, with internal whitespace being ignored.
A list of multiple, alternate, URLs may be specified by a comma-
separated list of angle-bracket enclosed URLs. The URLs have
precedence from left to right. The client application will use the
leftmost 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. It is
recommended that, at minimum, a mailto URL be provided wherever
possible.
The use of URLs allows for the use of the syntax with existing URL The use of URLs allows for the use of the syntax with existing URL
supporting applications. As the standard for URLs is extended, the supporting applications. As the standard for URLs is extended, the
list headers will gain the benefit of those extensions. list header fields will gain the benefit of those extensions.
Additionally, the use of URLs provides access to multiple transport Additionally, the use of URLs provides access to multiple transport
protocols (such as ftp and http) although it is expected that the protocols (such as ftp and http) although it is expected that the
"mailto" protocol will be the focus of most use of the list headers. "mailto" protocol 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 - no web access).
Command syntaxes requiring variable fields to be set by the client Command syntaxes requiring variable fields to be set by the client
(such as including the user's email address within a command) are not (such as including the user's email address within a command) are not
supported by this implementation at this time. However, systems supported by this implementation at this time. However, systems
using such syntaxes may still take advantage of the List-Help header using such syntaxes may still take advantage of the List-Help field
to provide the user with detailed instructions as needed or - to provide the user with detailed instructions as needed or -
perhaps more usefully - provide access to a web based command perhaps more usefully - provide access to some form of structured
interface. command interface such as a web based form.
The additional complications of supporting variable fields within the The additional complications of supporting variable fields within the
command syntax was determined to be too difficult to support at this command syntax was determined to be too difficult to support at this
stage and would compromise the likelihood of implementation by stage and would compromise the likelihood of implementation by
software authors. software authors.
To allow for future extension, client applications must follow the To allow for future extension, client applications must follow the
following guidelines for handling the contents of the headers following guidelines for handling the contents of the header fields
described in this document: described in this document:
1) If the content of the header (following any leading whitespace) 1) If the content of the field (following any leading whitespace)
begins with any character other than the opening angle bracket begins with any character other than the opening angle bracket
'<', the header should be ignored. '<', the field should be ignored.
2) Any characters in the header after the first closing angle 2) Any characters following an angle bracket enclosed URL are to be
bracket '>' are to be ignored. ignored, unless a comma is the first character after the closing
angle bracket.
3. The Core Headers 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) is to be ignored.
This document presents three headers which will provide the command 3. The List Header Fields
syntax description for the 'core' functions of most email
distribution lists. The headers implemented on a given list should
be included on all posts to the list, and on other messages where the
message clearly applies to one distinct list. Only one header of
each type should be present in any given message, to avoid any
confusion on the part of the mail client.
The headers are presented in order of suggested priority. 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 posts to the list, and on other messages
where the message clearly applies to one distinct list. Only one
field of each type should be present in any given message, to avoid
any confusion on the part of the mail client.
3.1. List-Help 3.1. List-Help
The List-Help header is the most important of these header fields. The List-Help field is the most important of the header fields
It would be perfectly acceptable for a list manager to include only described in this document. It would be acceptable for a list manager
this header, since by definition it should direct the user to to include only this field, since by definition it should direct the
complete instructions for all other commands. Typically, this would user to complete instructions for all other commands. Typically, the
return the help file for the list or a web page with list URL specified would request the help file for the list or a web page
instructions. Of all four headers, this one is the most likely with list instructions. Of all the header fields, this one is the
candidate for an http URL rather than a mailto, since a web page can most likely candidate to include an http URL, since a web page can be
be used to provide a lot more information about the list, as well as used to provide a lot more information about the list, as well as a
a form interface for command access. form interface for command access.
Examples: Examples:
List-Help: <mailto:list@host.com?subject=help> List-Help: <mailto:list@host.com?subject=help>
List-Help: <mailto:list-manager@host.com?body=info> List-Help: <mailto:list-manager@host.com?body=info>
List-Help: <http://www.host.com/list/>
List-Help: <mailto:list-info@host.com> List-Help: <mailto:list-info@host.com>
List-Help: <ftp://ftp.host.com/list.txt> List-Help: <http://www.host.com/list/>, <mailto:list-info@host.com>
List-Help: <ftp://ftp.host.com/list.txt>,
<mailto:list@host.com?subject=help>
3.2. List-Unsubscribe 3.2. List-Unsubscribe
The URL of the List-Unsubscribe header should generally describe the The List-Unsubscribe field describes the command (preferably using
mail message (mailto) to directly unsubscribe the user (removing them mail) to directly unsubscribe the user (removing them from the list).
from the list). Alternately, the URL may connect the user to some
other mechanism (such as a web page) which performs this function.
Examples: Examples:
List-Unsubscribe: <mailto:list@host.com?subject=unsubscribe> List-Unsubscribe: <mailto:list@host.com?subject=unsubscribe>
List-Unsubscribe: List-Unsubscribe:
<mailto:list-request@host.com?subject=unsubscribe>
List-Unsubscribe:
<mailto:list-manager@host.com?body=unsubscribe%20list> <mailto:list-manager@host.com?body=unsubscribe%20list>
List-Unsubscribe: <http://www.host.com/list.cgi?cmd=unsub&lst=list>
List-Unsubscribe: <mailto:list-off@host.com> List-Unsubscribe: <mailto:list-off@host.com>
List-Unsubscribe: <http://www.host.com/list.cgi?cmd=unsub&lst=list>,
<mailto:list-request@host.com?subject=unsubscribe>
3.3. List-Subscribe 3.3. List-Subscribe
The URL of the List-Subscribe header should generally describe the The List-Subscribe field describes the command (preferably using
mail message (mailto) to directly subscribe the user (requesting mail) to directly subscribe the user (request addition to the list).
addition to the list). Alternately, the URL may connect the user to
some other mechanism (such as a web page ) which performs this
function.
Examples: Examples:
List-Subscribe: <mailto:list@host.com?subject=subscribe> List-Subscribe: <mailto:list@host.com?subject=subscribe>
List-Subscribe: <mailto:list-request@host.com?subject=subscribe> List-Subscribe: <mailto:list-request@host.com?subject=subscribe>
List-Subscribe: List-Subscribe:
<mailto:list-manager@host.com?body=subscribe%20list> <mailto:list-manager@host.com?body=subscribe%20list>
List-Subscribe: <http://www.host.com/list.cgi>
List-Subscribe: <mailto:list-on@host.com> 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.
Examples:
List-Post: <mailto:list@host.com>
List-Post: <mailto:moderator@host.com>
List-Post: <mailto:moderator@host.com?subject=list%20posting>
3.5. List-Owner
The List-Owner field identifies the path to contact a human
administrator for the list. The address may be that of a moderator,
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>
List-Owner: <mailto:grant@foo.bar>
List-Owner: <mailto:josh@foo.bar?Subject=list>
3.6. List-Archive
The List-Archive field describes the method for accessing 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/>
4. Security Considerations 4. Security Considerations
There are very few new security concerns generated with this There are very few new security concerns generated with this
proposal. Headers are an existing standard, designed to easily proposal. Message headers are an existing standard, designed to
accommodate new types. There may be concern with multiple headers easily accommodate new types. There may be concern with multiple
being inserted or headers being forged, but these are problems fields being inserted or headers being forged, but these are problems
inherent in Internet email, not specific to this proposal. Further, inherent in Internet email, not specific to the protocol described in
the implications are relatively harmless. this document. Further, the implications are relatively harmless.
Mail list processors should not allow any user-originated list header Mail list processors should not allow any user-originated list header
fields to pass through to their lists, lest they confuse the user and fields to pass through to their lists, lest they confuse the user and
have the potential to create security problems. have the potential to create security problems.
On the client side, there may be some concern with posts or commands On the client side, there may be some concern with posts or commands
being sent in error. It is suggested that the user have a chance to 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 confirm any action before it is executed. In the case of mailto, it
may be appropriate to create the correctly formatted message without may be appropriate to create the correctly formatted message without
sending it, allowing the user to see exactly what is happening and sending it, allowing the user to see exactly what is happening and
giving the user the ability to stop the message before it is sent. giving the user the ability to stop the message before it is sent.
Mail client applications should not support list header field URLs Mail client applications should not support list header field URLs
which could compromise the security of the user's system. This which could compromise the security of the user's system. This
includes the "file://" URL type which could potentially be used to includes the "file://" URL type which could potentially be used to
trigger the execution of a local application on some user systems. trigger the execution of a local application on some user systems.
skipping to change at page 5, line 29 skipping to change at page 7, line 10
Keith Moore <moore@cs.utk.edu> and Christopher Allen Keith Moore <moore@cs.utk.edu> and Christopher Allen
<ChristopherA@consensus.com> provided guidance on the standards <ChristopherA@consensus.com> provided guidance on the standards
process. process.
Appendix Appendix
A. Background Discussion A. Background Discussion
This proposal arose from discussions started on the ListMom-Talk This proposal arose from discussions started on the ListMom-Talk
Discussion List [2]. When the discussion reached a sufficient level, Discussion List [5]. When the discussion reached a sufficient level,
a separate list was formed for discussing this proposal, the List a separate list was formed for discussing this proposal, the List
Headers Mail List [3] for deeper discussion. We have included edited Headers Mail List [4] for deeper discussion. We have included edited
excerpts from that discussion here, in order to show some of the excerpts from that discussion here, in order to show some of the
alternatives examined and reasons for our decisions. alternatives examined and reasons for our decisions.
A.1. Multiple header fields vs. a single header field A.1. Multiple header fields vs. a single header field
Use of a single header field for transporting command meta-syntax was Use of a single header field for transporting command meta-syntax was
rejected for a number of reasons. rejected for a number of reasons.
Such a header would require the creation of a new meta-syntax in 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 order to describe the list commands (as opposed to the use of the
widely deployed URL syntax which was chosen for this implementation). widely deployed URL syntax which was chosen for this implementation).
Every additional layer of complexity and newness reduces the Every additional layer of complexity and newness reduces the
likelihood of actual implementation because it will require likelihood of actual implementation because it will require
additional work to support. Also, by using the existing URL syntax, additional work to support. Also, by using the existing URL syntax,
we can profit from the end users' knowledge of that syntax and we can profit from the end users' knowledge of that syntax and
ability to use it even if their client applications do not support ability to use it even if their client applications do not support
the list header fields. the list header fields.
Restricting the transport of meta-syntax to the use of a single Restricting the transport of meta-syntax to the use of a single
header field also introduces complications with header size header field also introduces complications with header field size
limitations. Most individual commands can easily be described in a limitations. Most individual commands can easily be described in a
single line, but describing a multitude of commands can take up many single line, but describing a multitude of commands can take up many
lines in the header and runs a greater risk of being modified by an lines in the field and runs a greater risk of being modified by an
existing server on route. existing server on route.
The client implementation is also easier with multiple headers, since The client implementation is also easier with multiple fields, since
each command can be supported and implemented individually, each command can be supported and implemented individually,
completely independent of the others. Thus, some list managers or completely independent of the others. Thus, some list managers or
mail clients can choose to implement a subset of the headers based on mail clients can choose to implement a subset of the fields based on
the specific needs of their individual lists. the specific needs of their individual lists.
Finally, this format is simple and well recognized, which reduces the Finally, the format described in this document is simple and well
chances of errors in implementation and parsing. recognized, which reduces the chances of errors in implementation and
parsing.
A.2. URLs vs. parameter lists A.2. URLs vs. parameter lists
URLs are already an established syntax which is flexible, URLs are already an established syntax which is flexible,
well-defined, and in wide spread use. As its definition matures and well-defined, and in wide spread use. As its definition matures and
expands, the abilities of the list headers will grow as well, without expands, the abilities of the list fields will grow as well, without
requiring modification of this proposal. URLs are well prepared to requiring modification of this proposal. URLs are well prepared to
handle future protocols and developments, and can easily describe the handle future protocols and developments, and can easily describe the
different existing access protocols such as mailto, http and ftp. different existing access protocols such as mailto, http and ftp.
Many clients already have functionality for recognizing, parsing, and Many clients already have functionality for recognizing, parsing, and
evaluating URLs, either internally or by passing the request to a evaluating URLs, either internally or by passing the request to a
helper application. This makes implementation easier and more helper application. This makes implementation easier and more
realistic. As an example, this existing support for URL parsing realistic. As an example, this existing support for URL parsing
allowed us to add prototype list header functionality to existing allowed us to add prototype list header functionality to existing
mail clients (Eudora and Emailer for the Macintosh) without modifying mail clients (Eudora and Emailer for the Macintosh) without modifying
the source code. their source code.
A.3. Why not just create a standard command language? A.3. Why not just create a standard command language?
A standard command language, supported by all email list services, A standard command language, supported by all email list services,
would go a long way to reducing the problems of list access that would go a long way to reducing the problems of list access that
currently plague existing services. It would reduce the amount of currently plague existing services. It would reduce the amount of
learning required by end users and allow for a number of common learning required by end users and allow for a number of common
support tools to be developed. support tools to be developed.
However, such standardization does pose problems in the areas of However, such standardization does pose problems in the areas of
multi-lingual support and the custom needs of individual mailing multi-lingual support and the custom needs of individual mailing
lists. The development of such a standard is also expected to be met lists. The development of such a standard is also expected to be met
with a slow adoption rate by software developers and list service with a slow adoption rate by software developers and list service
providers. providers.
These do not preclude the development of such a standard (in fact, it These points do not preclude the development of such a standard (in
would suggest that we should start sooner rather than later), but we fact, it would suggest that we should start sooner rather than
do need a solution that can be widely supported by the current list later), but we do need a solution that can be widely supported by the
services. current list services.
We can support most existing list manager command syntaxes without a We can support most existing list manager command syntaxes without a
standard command language. By using URLs, we allow alternate access standard command language. By using URLs, we allow alternate access
methods a standard command language probably wouldn't enable, such as methods a standard command language probably wouldn't enable, such as
web based control. web based control.
Finally, client support for a standard command language is not at all Finally, client support for a standard command language is not at all
clear or simple to implement. The variety and large number of clear or necessarily simple to implement. The variety and large
commands existing today would require complicated user interfaces number of commands existing today would require complicated user
which could be confusing and difficult to implement. By restricting interfaces which could be confusing and difficult to implement. By
this proposal to the core functions, the client implementation is restricting this proposal to the core functions, the client
much simpler, which significantly increases the likelihood of implementation is much simpler, which significantly increases the
implementation (as evidenced by the support already announced by some likelihood of implementation (as evidenced by the support already
client and server application authors) and makes the entire proposal announced by a number of client and server application authors).
more realistic.
A.4. Internationalization A.4. Internationalization
Multilingual support is up to the URL standard. If URLs support it, Multilingual support is up to the URL standard. If URLs support it,
this proposal supports. This is another advantage of using URLs as this proposal supports. This is another advantage of using URLs as
the building blocks of the headers. the building blocks for the list header fields.
A.5. Variable Substitution A.5. Variable Substitution
Variables would allow this proposal to accommodate pretty much every Variables would allow this proposal to accommodate pretty much every
existing list manager. However, it would immeasurably increase the existing list manager. However, it would immeasurably increase the
complexity of the entire proposal, and possibly involve redefining complexity of the entire proposal, and possibly involve redefining
the URL standard. 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 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 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 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) its text here; otherwise, do this" where "this" is either: (a)
substitute a constant string, or (b) fail. substitute a constant string, or (b) fail.
The reason you would want a facility like this is because some list The reason you would want a facility like this is because some list
server applications insist on having certain parameters like users' server applications insist on having certain parameters like users'
names, which the user agent might or might not know. e.g. listserv 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 insists on having a first name and a last name if you supply either
one. one.
Which would lead to something like the UNIX shell syntax, where Which could lead to something like the UNIX shell syntax, where
${foo-bar} means substitute the value of parameter "foo" if "foo" is ${foo-bar} means substitute the value of parameter "foo" if "foo" is
defined, else substitute the string "bar". Perhaps $foo would mean defined, else substitute the string "bar". Perhaps $foo would mean
"substitute the value of parameter foo if it is defined, else "substitute the value of parameter foo if it is defined, else
substitute the empty string" substitute the empty string"
This all seems far too complicated for the gains involved, especially This all seems far too complicated for the gains involved, especially
since the use of variables can often be avoided. since the use of variables can often be avoided.
The use of variables in the command syntaxes of list services appears 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. to be lessening and does not, in any case, apply to all commands.
While the unsubscribe and subscribe command header fields may not be While the unsubscribe and subscribe command header fields may not be
usable by those systems which require the use of variables, the help usable by those systems which require the use of variables, the help
field will still provide end users with a consistent point of access field will still provide end users with a consistent point of access
through which they can get support for their use of the list. 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? A.6. Why not use a specialized MIME part instead of header fields?
MIME parts were considered, but because most mail clients currently MIME parts were considered, but because most mail clients currently
either don't support MIME or are not equipped to handle such either don't support MIME or are not equipped to handle such
specialized parts - such an implementation would in problems for end specialized parts - such an implementation would result in problems
users. It is also not as easy for many list servers to implement for end users. It is also not as easy for many list servers to
MIME as it is to implement new headers. implement MIME as it is to implement new header fields.
However, we are looking at how to implement MIME support in the However, we are looking at the design of a MIME part to more fully
future when the software is able to handle it. describe list command syntax, as well as trying to find ways to get
it supported by the applicable software.
A.7. Why include a Subscribe command? A.7. Why include a Subscribe command?
Subscribe and Unsubscribe are the key commands needed by almost every Subscribe and Unsubscribe are the key commands needed by almost every
list. Other commands, such as digest mode, are not as widely list. Other commands, such as digest mode, are not as widely
supported. supported.
Additionally, users who have unsubscribed (before going on vacation, Additionally, users who have unsubscribed (before going on vacation,
or for whatever other reason) may want to resubscribe to a list. Or, or for whatever other reason) may want to resubscribe to a list. Or,
a message may be forwarded/bounced from a subscriber to a a message may be forwarded/bounced from a subscriber to a
non-subscriber. Or, the user may change addresses and want to non-subscriber. Or, the user may change addresses and want to
subscribe from their new address. Having the List-Subscribe header subscribe from their new address. Having the List-Subscribe field
available could certainly help in all these cases. available could certainly help in all these cases.
A.8. The Dangers of Header Bloat A.8. The Dangers of Header Bloat
At what point are there just too many header fields? It really 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 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 will never be aware of a field unless the client software provides
some alternative user interface to it (akin to the Reply-To header). 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 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. would be able to recognize the function of the URLs contained within.
We feel the flexibility afforded by this proposal (in that the The flexibility afforded by the protocol described in this document
header fields may be individually implemented as deemed appropriate) (in that the header fields may be individually implemented as deemed
provides list administrators with sufficient 'room to maneuver' to appropriate) provides list administrators with sufficient 'room to
meet their individual needs. maneuver' to meet their individual needs.
A.9. Additional header fields for future consideration
Some of the other headers fields which have been considered, but
which have been set aside for further study, are as follows:
List-Digest: a command URL to switch to digest mode.
List-Post: email address to post to as a mailto URL.
List-Admin: contact URL for list administrator (usually a human).
List-Archive: access URL for list archives (old messages).
List-Software: list processing software name and version
B. Client Implementation B. Client Implementation
B.1. Guidelines B.1. Guidelines
For 'mailto' URL based commands, mail client applications should For 'mailto' URL based commands, mail client applications are advised
provide specialized feedback (such as presenting a dialog or alert), to try to provide specialized feedback (such as presenting a dialog
instead of the actual command email message, asking for command or alert), instead of the actual command email message, asking for
confirmation from the user. The feedback should identify the message command confirmation from the user. The feedback should identify the
destination and command within a more descriptive explanation. For message destination and command within a more descriptive
example: explanation. For example:
"Do you want to send the unsubscription command 'unsubscribe "Do you want to send the unsubscription command 'unsubscribe
somelist' to 'somelist-request@some.host.com'? somelist' to 'somelist-request@some.host.com'?
Sending the command will result in your removal from the Sending the command will result in your removal from the
associated list." associated list."
If the user has multiple email addresses supported by the mail If the user has multiple email addresses supported by the mail
client, the client application should prompt the user for which client, the client application should prompt the user for which
address to use when subscribing or performing some other action where address to use when subscribing or performing some other action where
the address to use cannot be specifically determined. When the address to use cannot be specifically determined. When
unsubscribing or such, the address that is subscribed should be used, unsubscribing or such, the address that is subscribed should be used,
unless that is not known by the application and cannot be determined unless that is not known by the application and cannot be determined
from the message headers. from the message headers.
B.2. Implementation Options B.2. Implementation Options
The following implementation possibilities are suggested here to give The following implementation possibilities are suggested here to give
some idea why these new headers will be useful, and how they could be some idea as to why these new header fields will be useful, and how
supported. Prototype menu items and floating pallettes have already they could be supported. Prototype menu items and floating pallettes
been implemented in more than one mail client. have already been implemented in more than one mail client.
In most cases, it may be helpful to disable the commands when not In most cases, it may be helpful to disable the commands when not
applicable to the currently selected message. applicable to the currently selected message.
B.2.1. Key combinations and command lines B.2.1. Key combinations and command lines
On text based systems which utilize command lines or key On text based systems which utilize command lines or key
combinations, each header could be implemented as a separate command. combinations, each field could be implemented as a separate command.
Thus one combination would subscribe the user, another would Thus one combination would subscribe the user, another would
unsubscribe, a third request help, etc. The commands would only be unsubscribe, a third request help, etc. The commands would only be
available on messages containing the list headers. available on messages containing the list header fields.
B.2.2. Menu items B.2.2. Menu items
On graphical systems which have menus, these commands could take the 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 form of a menu or sub-menu of items. For example, a "Lists" menu
might appear when viewing messages containing the headers, with items might appear when viewing messages containing the header fields, with
named "Subscribe", "Unsubscribe" and "Get Help". This menu could be items named "Subscribe", "Unsubscribe", "Get Help", "Post Message to
disabled when not applicable to the current message or disappear List", "Contact List Owner" and "Access List Archive". This menu
entirely. could be disabled when not applicable to the current message or
disappear entirely.
B.2.3. Push Buttons and Pallettes B.2.3. Push Buttons and Pallettes
On graphical window systems, buttons could be placed in the window of 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 the message, a toolbar, or in a floating pallette of their own. Each
button could correspond to a header, with names "Subscribe", button could correspond to a command, with names "Subscribe",
"Unsubscribe" and "Get Help". These buttons or pallettes could be "Unsubscribe", "Get Help", "Post to List", "List Owner" and
disabled when not applicable to the current message or disappear "Archive". These buttons or pallettes could be disabled when not
entirely. applicable to the current message or disappear entirely.
B.2.4 Feedback to the User B.2.4 Feedback to the User
When putting up a dialog (or other feedback element) the client When putting up a dialog (or other feedback element) the client
application may find it useful to include an option for the user to application may find it useful to include an option for the user to
review (and possibly modify) the message before it is sent. The review (and possibly modify) the message before it is sent. The
application may also find it useful to provide a link to more application may also find it useful to provide a link to more
detailed context-sensitive assistance about mail list access in detailed context-sensitive assistance about mail list access in
general. general.
References References
[1] David H. Crocker, "Standard for the Format of ARPA [1] David H. Crocker, "Standard for the Format of ARPA
Internet Text Messages" RFC 822, August 1982. Internet Text Messages" RFC 822, August 1982.
<URL:ftp://ftp.internic.net/rfc/rfc822.txt> <URL:ftp://ftp.internic.net/rfc/rfc822.txt>
[2] P. Hoffman and L. Masinter, "The mailto URL scheme" [2] P. Hoffman and L. Masinter, "The mailto URL scheme"
'work in progress' January 1997. <URL:ftp://ftp.internic.net/ 'work in progress' January 1997. <URL:ftp://ietf.org/
/internet-drafts/draft-hoffman-mailto-url-00.txt> internet-drafts/draft-hoffman-mailto-url-01.txt>
[3] T. Berners-Lee, L. Masinter and M. McCahill, [3] T. Berners-Lee, L. Masinter and M. McCahill,
"Uniform Resource Locators (URL)" RFC 1738, December 1994. "Uniform Resource Locators (URL)" RFC 1738, December 1994.
<URL:ftp://ftp.internic.net/rfc/rfc1738.txt> <URL:ftp://ftp.internic.net/rfc/rfc1738.txt>
[4] "List-Header" Mail list. list-header@arpp.carleton.ca
<URL:http://arpp.carleton.ca/listspec/mail/>
<URL:http://arpp.carleton.ca/listspec/>
[5] "ListMom-Talk" Mail list. listmom-talk@skyweyr.com
<URL:http://cgi.skyweyr.com/ListMom.Home>
Editors' addresses Editors' addresses
Joshua D. Baer Joshua D. Baer
Box 273 Box 273
4902 Forbes Avenue 4902 Forbes Avenue
Pittsburgh, PA 15213-3799 Pittsburgh, PA 15213-3799
USA USA
Email: josh@skyweyr.com Email: josh@skyweyr.com
Grant Neufeld Grant Neufeld
Ottawa, Ontario Ottawa, Ontario
Canada Canada
Tel: 613-237-1161
Email: grant@acm.org Email: grant@acm.org
This document expires August 27, 1997 This document expires February 18, 1998
 End of changes. 63 change blocks. 
138 lines changed or deleted 192 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/