As per Relevance of the word resource, we have this rfc below:
Network Working Group P.
Request for Comments: 2368 Internet Mail
Updates: 1738, 1808 L.
Category: Standards Track Xerox
J.
Netscape
July 1998
The mailto URL
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document defines the format of Uniform Resource Locators (URL
for designating electronic mail addresses. It is one of a suite
documents which replace RFC 1738, 'Uniform Resource Locators',
RFC 1808, 'Relative Uniform Resource Locators'. The syntax
'mailto' URLs from RFC 1738 is extended to allow creation of more
822 messages by allowing the URL to express additional header
body fields
1.
The mailto URL scheme is used to designate the Internet
address of an individual or service. In its simplest form, a
URL contains an Internet mail address
For greater functionality, because interaction with some
may require message headers or message bodies to be specified as
as the mail address, the mailto URL scheme is extended to
setting mail header fields and the message body
2. Syntax of a mailto
Following the syntax conventions of RFC 1738 [RFC1738], a "mailto
URL has the form
Hoffman, et. al. Standards Track [Page 1]
RFC 2368 The mailto URL scheme July 1998
mailtoURL = "mailto:" [ to ] [ headers ]
to = #
headers = "?" header *( "&" header )
header = hname "="
hname = *
hvalue = *
"#mailbox" is as specified in RFC 822 [RFC822]. This means that
consists of zero or more comma-separated mail addresses,
including "phrase" and "comment" components. Note that all
reserved characters in "to" must be encoded: in particular
parentheses, commas, and the percent sign ("%"), which commonly
in the "mailbox" syntax
"hname" and "hvalue" are encodings of an RFC 822 header name
value, respectively. As with "to", all URL reserved characters
be encoded
The special hname "body" indicates that the associated hvalue is
body of the message. The "body" hname should contain the content
the first text/plain body part of the message. The mailto URL
primarily intended for generation of short text messages that
actually the content of automatic processing (such as "subscribe
messages for mailing lists), not general MIME bodies
Within mailto URLs, the characters "?", "=", "&" are reserved
Because the "&" (ampersand) character is reserved in HTML, any
URL which contains an ampersand must be spelled differently in
than in other contexts. A mailto URL which appears in an
document must use "&" instead of "&".
Also note that it is legal to specify both "to" and an "hname"
value is "to". That is
mailto:addr1%2C%20addr
is equivalent
mailto:?to=addr1%2C%20addr
is equivalent
mailto:addr1?to=addr
8-bit characters in mailto URLs are forbidden. MIME encoded words (
defined in [RFC2047]) are permitted in header values, but not for
part of a "body" hname
Hoffman, et. al. Standards Track [Page 2]
RFC 2368 The mailto URL scheme July 1998
3. Semantics and
A mailto URL designates an "internet resource", which is the
specified in the address. When additional headers are supplied,
resource designated is the same address, but with an
profile for accessing the resource. While there are
resources that can only be accessed via electronic mail, the
URL is not intended as a way of retrieving such
automatically
In current practice, resolving URLs such as those in the "http
scheme causes an immediate interaction between client software and
host running an interactive server. The "mailto" URL has
semantics because resolving such a URL does not cause an
interaction. Instead, the client creates a message to the
address with the various header fields set as default. The user
edit the message, send this message unedited, or choose not to
the message. The operation of how any URL scheme is resolved is
mandated by the URL specifications
4. Unsafe
The user agent interpreting a mailto URL SHOULD choose not to
a message if any of the headers are considered dangerous; it may
choose to create a message with only a subset of the headers given
the URL. Only the Subject, Keywords, and Body headers are
to be both safe and useful
The creator of a mailto URL cannot expect the resolver of a URL
understand more than the "subject" and "body" headers. Clients
resolve mailto URLs into mail messages should be able to
create RFC 822-compliant mail messages using the "subject" and "body
headers
5.
RFC 1738 requires that many characters in URLs be encoded.
affects the mailto scheme for some common characters that
appear in addresses, headers or message contents. One such
is space (" ", ASCII hex 20). Note the examples above that use "%20"
for space in the message body. Also note that line breaks in
body of a message MUST be encoded with "%0D%0A".
People creating mailto URLs must be careful to encode any
characters that are used in the URLs so that properly-written
interpreters can read them. Also, client software that reads
must be careful to decode strings before creating the mail message
Hoffman, et. al. Standards Track [Page 3]
RFC 2368 The mailto URL scheme July 1998
that the mail messages appear in a form that the recipient
understand. These strings should be decoded before showing the
the message
The mailto URL scheme is limited in that it does not provide
substitution of variables. Thus, a message body that must include
user's email address can not be encoded using the mailto URL.
limitation also prevents mailto URLs that are signed with public
and other such variable information
6.
URLs for an ordinary individual mailing address
A URL for a mail response system that requires the name of the
in the subject
A mail response system that requires a "send" request in the body
A similar URL could have two lines with different "send" requests (
this case, "send current-issue" and, on the next line, "send index".)
issue%0D%0Asend%20index
An interesting use of your mailto URL is when browsing archives
messages. Each browsed message might contain a mailto URL like
To=%3c3469A91.D10AF4C@example.com
A request to subscribe to a mailing list
subscribe%20bamboo-l
A URL for a single user which includes a CC of another user
Another way of expressing the same thing
Hoffman, et. al. Standards Track [Page 4]
RFC 2368 The mailto URL scheme July 1998
Note the use of the "&" reserved character, above. The
example, by using "?" twice, is incorrect
; WRONG
According to RFC 822, the characters "?", "&", and even "%" may
in addr-specs. The fact that they are reserved characters in this
scheme is not a problem: those characters may appear in mailto URLs
they just may not appear in unencoded form. The standard URL
mechanisms ("%" followed by a two-digit hex number) must be used
certain cases
To indicate the address "gorby%kremvax@example.com" one would do
To indicate the address "unlikely?address@example.com", and
another header, one would do
unlikely%3Faddress@example.com?blat=foop
As described above, the "&" (ampersand) character is reserved in
and must be replacded with "&". Thus, a complex URL that
internal ampersands might look like
mailto:?to=joe@xyz.com&cc=bob@xyz.com&body=hello
send a greeting message to Joe and Bob.
7. Security
The mailto scheme can be used to send a message from one user
another, and thus can introduce many security concerns. Mail
can be logged at the originating site, the recipient site,
intermediary sites along the delivery path. If the messages are
encoded, they can also be read at any of those sites
A mailto URL gives a template for a message that can be sent by
client software. The contents of that template may be opaque
difficult to read by the user at the time of specifying the URL
Thus, a mail client should never send a message based on a mailto
without first showing the user the full message that will be
(including all headers that were specified by the mailto URL),
decoded, and asking the user for approval to send the message
electronic mail. The mail client should also make it clear that
user is about to send an electronic mail message, since the user
not be aware that this is the result of a mailto URL
Hoffman, et. al. Standards Track [Page 5]
RFC 2368 The mailto URL scheme July 1998
A mail client should never send anything without complete
to the user of what is will be sent; it should disclose not only
message destination, but also any headers. Unrecognized headers,
headers with values inconsistent with those the mail client
normally send should be especially suspect. MIME headers (MIME
Version, Content-*) are most likely inappropriate, as are
relating to routing (From, Bcc, Apparently-To, etc.)
Note that some headers are inherently unsafe to include in a
generated from a URL. For example, headers such as "From:", "Bcc:",
and so on, should never be interpreted from a URL. In general,
fewer headers interpreted from the URL, the less likely it is that
sending agent will create an unsafe message
Examples of problems with sending unapproved mail include
* mail that breaks laws upon delivery, such as making
threats
* mail that identifies the sender as someone interested in
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
damage that might be attributed to the sender
Programs that interpret mailto URLs should ensure that the
"From" address is set and correct
8. IANA
This document changes the definition of the mailto: URI scheme;
registry of URI schemes should refer to this document rather than
predecessor, RFC 1738.
Hoffman, et. al. Standards Track [Page 6]
RFC 2368 The mailto URL scheme July 1998
9.
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet
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",
1808, June 1995.
[RFC2047] Moore, K., "MIME Part Three: Message Header Extensions
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
addr-spec (not a full mailbox.) However, required usage
implementation has led to the development of an extended syntax
included more header fields
B.
This document was derived from RFC 1738 and RFC 1808 [RFC1808];
acknowledgments from those specifications still applies
The following people contributed to this memo or had and
similar ideas for mailto
Harald
Bryan
Steve
Al
Mark
Laurence
Keith
Jacob
Michael
Hoffman, et. al. Standards Track [Page 8]
RFC 2368 The mailto URL scheme July 1998
C. Author Contact
Paul E.
Internet Mail
127 Segre
Santa Cruz, CA 95060
EMail: phoffman@imc.
Larry
Xerox
3333 Coyote Hill
Palo Alto, CA 94304
EMail: masinter@parc.xerox.
Jamie
Netscape Communications Corp
501 East Middlefield
Mountain View, CA 94043
EMail: jwz@netscape.
Hoffman, et. al. Standards Track [Page 9]
RFC 2368 The mailto URL scheme July 1998
D. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Hoffman, et. al. Standards Track [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
