rfc2369.txt

RFC 的详细文档！


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:[e-mail]?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 <[e-mail]> and Christopher Allen
   <[e-mail]> 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