rfc2368.txt

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


RFC 2368                 The mailto URL scheme                 July 1998


   A mail client should never send anything without complete disclosure
   to the user of what is will be sent; it should disclose not only the
   message destination, but also any headers. Unrecognized headers, or
   headers with values inconsistent with those the mail client would
   normally send should be especially suspect. MIME headers (MIME-
   Version, Content-*) are most likely inappropriate, as are those
   relating to routing (From, Bcc, Apparently-To, etc.)

   Note that some headers are inherently unsafe to include in a message
   generated from a URL. For example, headers such as "From:", "Bcc:",
   and so on, should never be interpreted from a URL. In general, the
   fewer headers interpreted from the URL, the less likely it is that a
   sending agent will create an unsafe message.

   Examples of problems with sending unapproved mail include:

     * mail that breaks laws upon delivery, such as making illegal
       threats;

     * mail that identifies the sender as someone interested in breaking
       laws;

     * mail that identifies the sender to an unwanted third party;

     * mail that causes a financial charge to be incurred on the sender;

     * mail that causes an action on the recipient machine that causes
       damage that might be attributed to the sender.

   Programs that interpret mailto URLs should ensure that the SMTP
   "From" address is set and correct.

8. IANA Considerations

   This document changes the definition of the mailto: URI scheme; any
   registry of URI schemes should refer to this document rather than its
   predecessor, RFC 1738.














Hoffman, et. al.            Standards Track                     [Page 6]

RFC 2368                 The mailto URL scheme                 July 1998


9. 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, Editors,
             "Uniform Resource Locators (URL)", RFC 1738, December 1994.

   [RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC
             1808, June 1995.

   [RFC2047] Moore, K., "MIME Part Three: Message Header Extensions for
             Non-ASCII Text", RFC 2047, November 1996.






































Hoffman, et. al.            Standards Track                     [Page 7]

RFC 2368                 The mailto URL scheme                 July 1998


A. Change from RFC 1738

   RFC 1738 defined only a simple 'mailto' with no headers, just an
   addr-spec (not a full mailbox.)  However, required usage and
   implementation has led to the development of an extended syntax that
   included more header fields.

B. Acknowledgments

   This document was derived from RFC 1738 and RFC 1808 [RFC1808]; the
   acknowledgments from those specifications still applies.

   The following people contributed to this memo or had and discussed
   similar ideas for mailto.

   Harald Alvestrand
   Bryan Costales
   Steve Dorner
   Al Gilman
   Mark Joseph
   Laurence Lundblade
   Keith Moore
   Jacob Palme
   Michael Patton



























Hoffman, et. al.            Standards Track                     [Page 8]

RFC 2368                 The mailto URL scheme                 July 1998


C. Author Contact Information

   Paul E. Hoffman
   Internet Mail Consortium
   127 Segre Place
   Santa Cruz, CA  95060 USA

   EMail: [e-mail]


   Larry Masinter
   Xerox Corporation
   3333 Coyote Hill Road
   Palo Alto, CA 94304 USA

   EMail: [e-mail]


   Jamie Zawinski
   Netscape Communications Corp.
   501 East Middlefield Road
   Mountain View, CA 94043 USA

   EMail: [e-mail]



























Hoffman, et. al.            Standards Track                     [Page 9]

RFC 2368                 The mailto URL scheme                 July 1998


D.  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.
























Hoffman, et. al.            Standards Track                    [Page 10]