rfc2369.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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 '[e-mail]'?  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. [e-mail]
       <URL:http://www.nisto.com/listspec/mail/>
       <URL:http://www.nisto.com/listspec/>

   [6] "ListMom-Talk" Mail list. [e-mail]
       <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: [e-mail]


   Grant Neufeld
   Calgary, Alberta
   Canada

   EMail: [e-mail]
   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]