Last update: April 12, 1997
Grant Neufeld - <email@example.com>
This sub-document discusses possibilities for a general meta-syntax to describe the various list processor command syntaxes.
Note: The discussion of variable fields in URLs is going to move from this proposal to a more broader discussion of the mailto URL in general (and possibly other URL protocols). Implementation of variables in the command URLs used by this proposal will be dependent upon the specification of variables in the general mailto URL standard.
Command URLs may contain references to the user's name, email address, or other client defined arguments through the inclusion of variable fields.
Variables (such as the user's email address) are to be enclosed in a special variable delimiting character pair.
The delimiters to be used square brackets
For example, a list subscription command requiring the user to supply
their real name within the command ("
subscribe maillist [Your Name Here]")
could be described as follows:
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.
Reasons for not including the brackets as plaintext rather than hex-encoding them:
|Variable Label||-|| Description|
|-|| user's real name|
|-|| user's email address (may need to prompt the user to select an address if they have multiple addresses supported by the client software)|
|-|| user's password (for the listserver)|
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).
The abbreviation must
be followed by the specific terminology used by the server enclosed in round
()"). E.g., a server that
uses the term "remove" for the unsubscribe command, would list
If using an URL to describe a syntax, it must be enclosed in angle brackets as in
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
|-|| subscribe to list|
|-|| unsubscribe from list|
|-|| receive digests|
|-|| regular messages, not digest format|
|-|| acknowledgements (sender receives messages they've posted)|
|-|| no acknowledgements|
|-|| get help file|
|-|| get info file|
|-|| set password|
|-|| get a file from the archive of this list|
|-|| index, to retrieve back digests|
|-|| topics only|
|-|| full headers|
|-|| short headers|
|-|| get the FAQ for this list|
|-|| get the list of subscribers for this list|
These are used to identify various aspects of the list.
|-||announcements only list|
|-||no posting allowed to this list|
|-||newsletter (periodical) list|
|-||file distribution list|
|-||list includes/allows file enclosures|
|-||enclosures not permitted|
|-||password required for commands|
|-||you MAY archive this list|
|-||you may NOT archive this list|
Not all of the protocols described here are
intended for actual use at this time. Only those portions which undergo
some form of peer-review or standards formalization should be deployed.
This document may be redistributed provided this copyright notice remains intact.