http://arpp.carleton.ca/midas/mail/list-header.html
This is the current draft of the discussion paper. I advise you to look at
the web page instead of reading it here, if you can, since it's a bit
easier to read on the web (and being updated more often).
A reduced proposal is being put together for quick implementation. It
consists of just the List-Help, List-Unsubscribe, and List-Subscribe
headers. This will be posted here as well, when it's ready.
Please try to keep discussion to the ListMom-Talk maillist
<http://search.skyweyr.com/lists/ListMom.Home>
Thanks.
- - - - - - - - - - - - - - - - - -
List Specification Headers Proposal
Discussion Paper; Version 0.0.9; February 15, 1997
Grant Neufeld - <grant@acm.org>
Active discussion is presently taking place on the following mail lists
(primarily on ListMom-Talk):
* ListMom-Talk <listmom-talk@skyweyr.com>,
* List-Managers <Majordomo@GreatCircle.COM>
* Net-Thinkers <net-thinkers@rthumper.vmeng.com>
Note: This is a discussion document only and as such is subject to
tremendous, contradictory change. It is not a standard, nor even a
proposed standard (yet).
________________________________________________________________________
Introduction
The following is a discussion toward a proposal for new RFC type
message headers to be used to identify electronic mailing list features
and command sets to mail clients.
It is expected that by implementing a standard format for list server
identifier headers, mail client software developers could implement
interface features to make mail list control easier for users (when the
headers are present). For example, GUI mail client could potentially
offer buttons to un/subscribe, get list info, or switch to digest mode.
An important consideration in this discussion is avoiding adding a
tonne of new headers and 'bulking up' messages that are already often
heavy with headers and other administrative info (e.g., list info
footers).
The IETF has not been contacted yet because this is just a preliminary
discussion. Once something a bit more solid has been put together, this
proposal may be presented to a formal standards process.
We still need to figure out how to handle 'partner' lists such as when
there is a separate digest lists and users need to unsub the regular
list and sub the digest list in order to switch to digests.
________________________________________________________________________
Discussion
Alex Hoppman wrote: "There is a more general issue of mail client
capability discovery (IE: How does my mail client know that your client
understands Binhex and Text/Enriched but not text/html?)."
For systems requiring mailback authentication to confirm subscriptions
(and/or other commands), it would be useful to standardize the mailback
message format - or at least provide a header which gives instructions
the client application can use to provide a confirmation interface to
the user (E.g., Dialog saying: "Confirmation request received for
subscription to MAIL-LIST. Do you wish to accept the subscription?").
What about time-to-live (expiry) issues?
Client software authors, if they want to implement support
for the headers prior to this proposal becoming formalized should
support both "X-List-" and "List-" prefixes for any of the List Headers
they support. Supporting both formats is important so that servers
don't have to include both formats in outgoing messages just to support
old versions of client software.
________________________________________________________________________
Syntax
Headers
Note that the already defined 'Sender' header should still be used to
identify the list name and address.
Note that client software should recognize and support both
the "List-" and "X-List-" prefixes as the same thing. Until this
proposal is formalized (as an RFC or such), servers should format
outgoing headers with the "X-List-" prefix.
URLs must be enclosed in angle brackets <>.
<token> are required elements.
[token] are optional elements.
List-Commands:
<comma separated list of command abbreviations>
List-Attributes:
[comma separated list of list attributes]
Changed from List-Info to List-Attributes.
List-Post:
<address to post to (useful when using a moderator)>
[; [text token to prepend to subject]]
List-Subscribe:
<command URL (e.g., <http://www.server.com/maillist/>)>
List-Unsubscribe:
<command URL (e.g.,
<mailto:listserv@server.com?Body=unsubscribe%20maillist>)>
List-Digest:
<command URL (e.g.,
<mailto:listcontrol@server.com?Body=set%20digest%20maillist>)>
List-Help:
<help URL (e.g., <mailto:listcontrol@server.com?Subject=help>)>
List-Help is just a general purpose URL or mail address for
the user to get information and help with the list, and possibly for
web-controlled subscription management. It should point to a central
spot from which the user can access all the information available about
the list (description, command instructions, archives, human admin,
etc.).
(alternative headers that can be interpreted the same way: List-Home:,
X-URL:, List-URL:)
List-Settings:
[comma separated list of command abbreviations]
The subscriber's particular settings.
List-Control:
<list server control email address or URL>
Server's address for control (command)messages.
List-Admin:
<list adadministrator email address or URL>
List administrator (list-manager, list-mom) contact address
(usually a human).
List-Software:
<SoftwareName> <Version> by <Author>
Name and version of the mailing list management software in
use. Note that this is strictly an optional tag and provides no
functional use. As Joshua D. Baer put it, this is one for the
marketing folks.
Header Sub-Elements
Variable Fields
Variables (such as the user's email address) are to be enclosed in a
special variable delimiting character pair.
Currently the square brackets [] seem to be the preference, although
this is under discussion. Alternates under consideration include: {},
**, ^^, ~~ .
Optional variables (e.g., "subscribe maillist [username]") could be
described using double delimiters. e.g.,
mailto:control@server.com?Body=subscribe%20maillist%20[[username]]
would mean that including the username is optional, whereas
mailto:control@server.com?Body=subscribe%20maillist%20[username]
would mean that including the username is required.
Note that it's up to the client software to determine what to put into
the variable. If uncertain, the user should be prompted to enter the
variable argument.
Variable Label - Description
username - user's real name
useremail - user's email address (may need to prompt the user
to select an address if they have multiple addresses
supported by the client software)
password - user's password (for the listserver)
argument - some user selected argument (may need to pop up a
dialog or something to get the value from the user)
Command Abbreviations
These are used to identify which types of commands the list supports.
The abbreviations consist of three characters from A to Z (generally
uppercase, although applications should treat them as
case-insensitive).
If the server's syntax for the command deviates from the standard for
the command, the abbreviation will be followed by the specific
terminology used by the server enclosed in either round or curly
brackets ("()" or "{}"). E.g., a server that uses the term "remove",
instead of the standard "unsubscribe", would list "UNS(remove)".
If using an URL to describe a syntax, it must be enclosed in angle
brackets as in "SUB<http://server.com/mylist.cgi?action=subscribe>".
There there may be multiple entries for a single command. E.g.,
"FAQ(get faq listname), FAQ<http://server.com/listname/faq.html>". The
user or client application will have to choose which one to use based
on their preference.
Abb - Standard Syntax - Description
SUB - subscribe <listname> - subscribe to list
UNS - unsubscribe <listname> - unsubscribe from list
DIG - set digest <listname> - receive digests
REG - set nodigest <listname> - regular messages, not digest format
ACK - set ack <listname> - acknowledgements (sender receives
messages they've posted)
NCK - set no-ack <listname> - no acknowledgements
HLP - help <listname> - get help file
INF - info <listname> - get info file
PSW - set password [password] - set password
GET - get [argument] <listname> - get a file from the archive of this list
IND - get index <listname> - index, to retrieve back digests
TOP - set topics <listname> - topics only
FUL - set full-head <listname> - full headers
SHH - set short-head <listname> - short headers
FAQ - get faq <listname> - get the FAQ for this list
WHO - who <listname> - get the list of subscribers for this list
List Attributes
These are used to identify various aspects of the list.
Abb - Description
PUB - public list
PRI - private list
MOD - moderated list
ANN - announcements only list
NPO - no posting allowed to this list
NWS - newsletter (periodical) list
ADV - advertising list
FIL - file distribution list
ENC - list includes/allows file enclosures
NOE - enclosures not permitted
PWR - password required for commands
ACH - you MAY archive this list
NOA - you may NOT archive this list
________________________________________________________________________
Implementation
Client applications are encouraged to put up a dialog/alert
(not a window with the actual command email message) asking for command
confirmation. For example, if the application has provided an
"Unsubscribe" button, which is mapped to the command url
"<mailto:control@server.com?Body=unsubscribe%20maillist>", it should
present an alert of the form:
Are you sure you want to unsubscribe from the "maillist" mailing list?
You will no longer receive copies of messages submitted to the list.
|Cancel| |Unsubscribe|
The client application may want to provide a preference/configuration
setting to allow the user to turn off the confirmation alerts.
Alert Standard Messages
Client application authors are strongly encouraged to use the following
standard messages in their mail software supporting the Mail List
Headers.
Once we get these finalized, we should arrange for standard messages in
other languages, too.
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, just use the address that is subscribed, unless
that cannot be determined from the message headers.
Subscribe
Do you want to subscribe to the mail list "<listname>"?
Every message sent to the list will be individually forwarded to your
mailbox. (<username> <<useraddress>>)
|Cancel| |Subscribe|
Unsubscribe
Are you sure you want to unsubscribe from the "<listname>" mailing
list?
You will no longer receive copies of messages submitted to the list.
|Cancel| |Unsubscribe|
Digests On
Are you sure you want to subscribe to the digest format of the
"<listname>" mailing list?
New digests will be forwarded as email to your mailbox. (<username>
<<useraddress>>)
|Cancel| |Digests|
Digests Off (Regular On)
Are you sure you want to subscribe to the regular format of the
"<listname>" mailing list?
Every message sent to the list will be individually forwarded
(non-digest mode) to your mailbox. (<username> <<useraddress>>)
|Cancel| |Subscribe|
________________________________________________________________________
See Also
The enhanced mailto URL internet draft by Paul Hoffman and Larry Masinter.
ftp://ftp.internic.net//internet-drafts/draft-hoffman-mailto-url-00.txt
________________________________________________________________________
Discussion Paper Only - not intended for general use until such time as
it has undergone some form of peer-review or standards formalization.
Copyright 1997 by Grant Neufeld.
This document may not be redistributed in any form without prior
permission of the author.
Permission is granted to redistribute in whole or in part on the
electronic mailing lists listed at the beginning of this document.
[This copyright is being held to prevent this paper from being
redistributed outside of its intended audience. When a formal proposal
for standardization is made, the distribution restrictions will be
lifted, and the formal proposal will most likely be placed in the
public domain or under the control of a recognized standards body.]
--
gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*>
Follow-Ups:
|
|
