Network Working Group M. Duerst Internet-Draft Aoyama Gakuin University Obsoletes: 2368 (if approved) L. Masinter Expires: September 7, 2006 Adobe Systems Incorporated J. Zawinski DNA Lounge March 6, 2006 The 'mailto' URI Scheme draft-duerst-mailto-bis-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 7, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines the format of Uniform Resource Identifiers (URI) for references to electronic mail addresses. It updates the syntax of 'mailto' URIs from [RFC2368] for better compatibility with IRIs ([RFC3987]). Duerst, et al. Expires September 7, 2006 [Page 1]
Internet-Draft The 'mailto' URI Scheme March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Syntax of a mailto URI . . . . . . . . . . . . . . . . . . . . 3 3. Semantics and Operations . . . . . . . . . . . . . . . . . . . 5 4. Unsafe Headers . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Deployment of UTF-8-Based Percent-Encoding . . . . . . . . . . 7 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Examples Conforming to RFC2368 . . . . . . . . . . . . . . 7 7.2. Examples of Complicated Email Addresses . . . . . . . . . 8 7.3. Examples Using UTF-8-Based Percent-Encoding . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Changes between draft 01 and draft 02 . . . . . . . . . . 12 10.2. Changes between draft 00 and draft 01 . . . . . . . . . . 12 10.3. Changes from RFC 2368 . . . . . . . . . . . . . . . . . . 13 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Duerst, et al. Expires September 7, 2006 [Page 2]
Internet-Draft The 'mailto' URI Scheme March 2006 1. Introduction The mailto URI scheme is used to identify resources that are reached using Internet mail. In its simplest form, a mailto URI contains an Internet mail address. For interaction with resources that requires message headers or message bodies to be specified, the mailto URI scheme also allows setting mail header fields and the message body. This specification extends the previous scheme definition to also allow character data to be percent-encoded based on UTF-8, which offers a better and more consistent way of dealing with non-ASCII characters. In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119]. 2. Syntax of a mailto URI The syntax of a "mailto" URI is described using the ABNF of [RFC4234], and non-terminal definitions from [RFC2822] (domain, dot- atom, quoted-string) and [RFC3986] (unreserved, pct-encoded): mailtoURI = "mailto:" [ to ] [ headers ] to = [ addr-spec *("%2C" addr-spec ) ] headers = "?" header *( "&" header ) header = hname "=" hvalue hname = *qchar hvalue = *qchar addr-spec = local-part "@" domain local-part = dot-atom / quoted-string qchar = unreserved / pct-encoded / some-delims some-delims = "!" / "$" / "'" / "(" / ")" / "*" / "+" / "," / ";" / ":" / "@" "addr-spec" is as specified in [RFC2822], i.e. it is a mail address, possibly including "phrase" and "comment" components. However, the following changes apply: 1. A number of characters that can appear in "addr-spec" have to be percent-encoded. These are the characters that cannot appear in an URI according to [RFC3986] as well as "%" (because it is used for percent-encoding) and all the characters in gen-delims except "@" (i.e. "/", "?", "#", "[" and "]"). Of the characters in sub- delims, at least the following also have to be percent-encoded: "&", ";", and "=". Care has to be taken both when encoding as well as when decoding to make sure these operations are applied Duerst, et al. Expires September 7, 2006 [Page 3]
Internet-Draft The 'mailto' URI Scheme March 2006 only once. 2. "obs-local-part" and "NO-WS-CTL" as defined in [RFC2822] are not allowed. 3. Whitespace and comments within "local-part" are not allowed. They do not have any operational semantics. 4. Percent-encoding can be used to denote non-ASCII characters in the part of a "mailbox" that denotes a domain name, in order to denote an internationalized domain name. The considerations for reg-name in [RFC3986] apply. In particular, non-ASCII characters must first be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence must be percent-encoded to be represented as URI characters. URI producing applications must not use percent-encoding in domain names unless it is used to represent a UTF-8 character sequence. When the internationalized domain name is used to compose a message, the name must be transformed to the IDNA encoding [RFC3490]. URI producers should provide these domain names in the IDNA encoding, rather than percent-encoded, if they wish to maximize interoperability with legacy mailto: URI interpreters. 5. Percent-encoding of non-ASCII octets in the LHS of an email address is reserved for potential future internationalization. Non-ASCII characters must first be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence must be percent-encoded to be represented as URI characters. Any other percent-encoding of non-ASCII characters is prohibited. When a LHS containing non-ASCII characters will be used to compose a message, the LHS must be transformed to conform to whatever encoding may be defined in a future specification for the internationalization of email addresses. "hname" and "hvalue" are encodings of an [RFC2822] header field name and value, respectively. Percent-encoding is needed for the same characters as listed above for "addr-spec". The special hname "body" indicates that the associated hvalue is the body of the message. The "body" hname should contain the content for the first text/plain body part of the message. The "body" hname is primarily intended for generation of short text messages for automatic processing (such as "subscribe" messages for mailing lists), not general MIME bodies. Within mailto URIs, the characters "?", "=", and "&" are reserved. Because the "&" (ampersand) character is reserved in HTML and XML, Duerst, et al. Expires September 7, 2006 [Page 4]
Internet-Draft The 'mailto' URI Scheme March 2006 any mailto URI which contains an ampersand must be spelled differently in HTML and XML than in other contexts. A mailto URI which appears in an HTML or XML document must escape the "&", e.g. as "&". Non-ASCII characters can be encoded in hvalue as follows: 1. MIME encoded words (as defined in [RFC2047]) are permitted in header values, but not in an hvalue of a "body" hname. 2. Non-ASCII characters can be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence is percent-encoded to be represented as URI characters. When hvalues encoded in this way are used to compose a message, the hvalue must be transformed into MIME encoded words, except for an hvalue of a "body" hname, which has to be encoded according to [RFC2045]. Please note that for MIME encoded words and for bodies in composed email messages, encodings other than UTF-8 MAY be used as long as the characters are properly transcoded. MIME encoded words and UTF-8-based percent-encoding SHOULD NOT both be used sequentially in the same hvalue, and MUST NOT be combined. Also note that it is legal to specify both "to" and an "hname" whose value is "to". That is, <mailto:addr1@an.example%2C%20addr2@an.example> is equivalent to <mailto:?to=addr1@an.example%2C%20addr2@an.example> is equivalent to <mailto:addr1@an.example?to=addr2@an.example> However, the latter form is NOT RECOMMENDED. Implementations should be careful not to produce two "To:" header fields in a message. Also, creators of mailto: URIs should be careful to not include message header fields multiple times if these header fields can only be used once in a message. 3. Semantics and Operations A mailto URI designates an "internet resource", which is the mailbox specified in the address. When additional headers are supplied, the resource designated is the same address, but with an additional Duerst, et al. Expires September 7, 2006 [Page 5]
Internet-Draft The 'mailto' URI Scheme March 2006 profile for accessing the resource. While there are Internet resources that can only be accessed via electronic mail, the mailto URI is not intended as a way of retrieving such objects automatically. In current practice, resolving URIs such as those in the "http" scheme causes an immediate interaction between client software and a host running an interactive server. The "mailto" URI has unusual semantics because resolving such a URI does not cause an immediate interaction. Instead, the client creates a message to the designated address with the various header fields set as default. The user can edit the message, send this message unedited, or choose not to send the message. The operation of how any URI scheme is resolved is not mandated by the URI specifications. 4. Unsafe Headers The user agent interpreting a mailto URI SHOULD choose not to create a message if any of the headers are considered dangerous; it may also choose to create a message with only a subset of the headers given in the URI. Only a limited set of headers such as the Subject, Keywords, and Body headers are believed to be both safe and useful in the general case. In cases where the source of an URI is well known, and/or specific fields are limited to specific well-known values, other headers may be considered safe, too. The creator of a mailto URI cannot expect the resolver of a URI to understand more than the "subject" and "body" headers. Clients that resolve mailto URIs into mail messages should be able to correctly create [RFC2822]-compliant mail messages using the "subject" and "body" headers. 5. Encoding [RFC3986] requires that many characters in URIs be encoded. This affects the mailto scheme for some common characters that might appear in addresses, headers or message contents. One such character is space (" ", ASCII hex 20). Note the examples below that use "%20" for space in the message body. Also note that line breaks in the body of a message MUST be encoded with "%0D%0A". People creating mailto URIs must be careful to encode any reserved characters that are used in the URIs so that properly-written URI interpreters can read them. Also, client software that reads URIs must be careful to decode strings before creating the mail message so that the mail messages appear in a form that the recipient will Duerst, et al. Expires September 7, 2006 [Page 6]
Internet-Draft The 'mailto' URI Scheme March 2006 understand. These strings should be decoded before showing the message to the user. The mailto URI scheme is limited in that it does not provide for substitution of variables. Thus, a message body that must include a user's email address can not be encoded using the mailto URI. This limitation also prevents mailto URIs that are signed with public keys and other such variable information. 6. Deployment of UTF-8-Based Percent-Encoding UTF-8-based percent-encoding should only be used in actual mailto URIs once it is well deployed in software that interprets mailto URIs (such as mail user agents). 7. Examples 7.1. Examples Conforming to RFC2368 URIs for an ordinary individual mailing address: <mailto:chris@example.com> A URI for a mail response system that requires the name of the file in the subject: <mailto:infobot@example.com?subject=current-issue> A mail response system that requires a "send" request in the body: <mailto:infobot@example.com?body=send%20current-issue> A similar URI could have two lines with different "send" requests (in this case, "send current-issue" and, on the next line, "send index".) <mailto:infobot@ example.com?body=send%20current-issue%0D%0Asend%20index> An interesting use of mailto URIs is when browsing archives of messages. A link can be provided that allows to reply to a message and conserve threading information. This is done by adding a In- Reply-To header containing the Message-ID of the message where the link is added, for example: <mailto:list@example.org?In-Reply-To=%3C3469A91.D10AF4C@ example.com%3E> Duerst, et al. Expires September 7, 2006 [Page 7]
Internet-Draft The 'mailto' URI Scheme March 2006 A request to subscribe to a mailing list: <mailto:majordomo@example.com?body=subscribe%20bamboo-l> A URI for a single user which includes a CC of another user: <mailto:joe@example.com?cc=bob@example.com&body=hello> Note the use of the "&" reserved character, above. The following example, by using "?" twice, is incorrect: <mailto:joe@example.com?cc=bob@example.com?body=hello> ; WRONG! According to [RFC2822], the characters "?", "&", and even "%" may occur in addr-specs. The fact that they are reserved characters in this URI scheme is not a problem: those characters may appear in mailto URIs, they just may not appear in unencoded form. The standard URI encoding mechanisms ("%" followed by a two-digit hex number) must be used in these cases. To indicate the address "gorby%kremvax@example.com" one would do: <mailto:gorby%25kremvax@example.com> To indicate the address "unlikely?address@example.com", and include another header, one would do: <mailto:unlikely%3Faddress@example.com?blat=foop> As described above, the "&" (ampersand) character is reserved in HTML and must be replaced e.g. with "&". Thus, a URI with an internal ampersand might look like: Click <a href="mailto:joe@an.example?cc=bob@an.example&body=hello"> mailto:joe@an.example?cc=bob@an.example&body=hello</a> to send a greeting message to Joe and Bob. 7.2. Examples of Complicated Email Addresses Following are a few examples of how to treat email addresses that contain complicated escaping syntax. Email address: "not@me"@example.org; corresponding mailto: URI: <mailto:%22not%40me%22@example.org>. Email address: "oh\\no"@example.org; corresponding mailto: URI: <mailto:%22oh%5C%5Cno%22@example.org>. Duerst, et al. Expires September 7, 2006 [Page 8]
Internet-Draft The 'mailto' URI Scheme March 2006 Email address: "\\\"it's\ ugly\\\""@example.org; corresponding mailto: URI: <mailto:%22%5C%5C%5C%22it's%22%20ugly%5C%5C%5C%22%22@example.org>. 7.3. Examples Using UTF-8-Based Percent-Encoding Sending a mail with the subject "coffee" in French, i.e. "cafe" where the final e is an e-acute, using UTF-8 and percent-encoding: <mailto:user@example.org?subject=caf%C3%A9> The same subject, this time using an encoded-word (escaping the "=" and "?" characters used in the encoded-word syntax, because they are reserved): <mailto:user@ example.org?subject=%3D%3Futf-8%3FQ%3Fcaf%3DC3%3DA9%3F%3D> The same subject, this time encoded as iso-8859-1: <mailto:user@ example.org?subject=%3D%3Fiso-8859-1%3FQ%3Fcaf%3DE9%3F%3D> Going back to straight UTF-8 and adding a body with the same value: <mailto:user@example.org?subject=caf%C3%A9&body=caf%C3%A9> This mailto URI may result in a message looking like this: From: sender@example.net To: user@example.org Subject: =?utf-8?Q?caf=C3=A9?= Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable caf=C3=A9 Duerst, et al. Expires September 7, 2006 [Page 9]
Internet-Draft The 'mailto' URI Scheme March 2006 The software sending the email is not restricted to UTF-8, but can use other encodings. The following shows the same email using iso- 8859-1 two times: From: sender@example.net To: user@example.org Subject: =?iso-8859-1?Q?caf=E9?= Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable caf=E9 Different content transfer encodings (i.e. "8bit" or "base64" instead of "quoted-printable") and different encodings in encoded words (i.e. "B" instead of "Q") can also be used. For more examples of encoding the word coffee in different languages, see [RFC2324]. The following example uses the Japanese word "natto" (U+7D0D U+8C46) as a domain name label, sending a mail to a user at "natto".example.org: <mailto:user@%E7%B4%8D%E8%B1%86.example.org?subject=Test&body=NATTO> When constructing the email, the domain name label is converted to punycode. The resulting message may look as follows: From: sender@example.net To: user@xn--99zt52a.example.org Subject: Test Content-Type: text/plain Content-Transfer-Encoding: 7bit NATTO 8. Security Considerations The mailto scheme can be used to send a message from one user to another, and thus can introduce many security concerns. Mail messages can be logged at the originating site, the recipient site, and intermediary sites along the delivery path. If the messages are not encoded, they can also be read at any of those sites. A mailto URI gives a template for a message that can be sent by mail client software. The contents of that template may be opaque or difficult to read by the user at the time of specifying the URI. Duerst, et al. Expires September 7, 2006 [Page 10]
Internet-Draft The 'mailto' URI Scheme March 2006 Thus, a mail client should never send a message based on a mailto URI without first showing the user the full message that will be sent (including all headers that were specified by the mailto URI), fully decoded, and asking the user for approval to send the message as electronic mail. The mail client should also make it clear that the user is about to send an electronic mail message, since the user may not be aware that this is the result of a mailto URI. A mail client should never send anything without complete disclosure to the user of what 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, except when added by the MUA to correctly encode the text(s) being sent, 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 URI. For example, headers such as "From:", "Bcc:", and so on, should never be interpreted from a URI. In general, the fewer headers interpreted from the URI, 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 URIs should ensure that the SMTP "From" address is set and correct, and that the resulting email is a complete, workable message. The security considerations of [RFC3986], [RFC3490], [RFC3491], and [RFC3987] also apply. Implementers and users are recommended to check them carefully. Duerst, et al. Expires September 7, 2006 [Page 11]
Internet-Draft The 'mailto' URI Scheme March 2006 9. IANA Considerations This document changes the definition of the mailto: URI scheme; the registry of URI schemes needs to be updated to refer to this document rather than its predecessor, [RFC2368]. TODO: Add registration for "Body" message header field to make sure it doesn't get used for something else. 10. Change Log 10.1. Changes between draft 01 and draft 02 Fixed phone/fax for Martin. Changed examples to reduce cases with both a 'to' field and a 'to' hname. Fixed syntax to not rely on non-terminals from RFC 2396. Changed description of set of characters that needs to be escaped. Mollified warning about headers other than Subject, Keywords, and Body. Clarified prohibition of mixing different encodings (%-escaping and Mime encoded words) for headers. Improved some examples. Fixed some terminology. 10.2. Changes between draft 00 and draft 01 Added clarification about permitted syntax and escaping on email address LHS, and more complicated examples. Added text about more save headers in case origin or mailto URIs is known. Fixed date of [RFC3986] Added a sentence referencing [RFC2119] Added Jamie back in as a co-author. Changed address/affiliation for Martin. Duerst, et al. Expires September 7, 2006 [Page 12]
Internet-Draft The 'mailto' URI Scheme March 2006 10.3. Changes from RFC 2368 For interoperability with IRIs ([RFC3987]), allowed percent- encoding, fixed to UTF-8, in the domain name part of an email address, in LHS part of an address (currently reserved because not operationally usable), and in hvalue parts. Changed from 'URL' to 'URI' Updated references: ABNF to [RFC4234]; message syntax to [RFC2822], URI Generic Syntax to [RFC3986] Expanded "#mailbox", because the "#" shortcut is no longer available; needs checking 11. Acknowledgments This document was derived from [RFC2368]; the acknowledgments from this specification still applies. In addition, we thank Paul Hoffman for his work on [RFC2368]. Valuable input on this document was received from (in no particular order): Paul Hoffman, Charles Lindsey, Tim Kindberg, Frank Ellermann, Etan Wexler, and Michael Haardt. 12. References 12.1. Normative References [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", November 1996. [RFC2047] Moore, K., "MIME Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2822] Resnik, P., "Internet Message Format", RFC 2822, April 2001. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. Duerst, et al. Expires September 7, 2006 [Page 13]
Internet-Draft The 'mailto' URI Scheme March 2006 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [STD63] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. 12.2. Informative References [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, April 1998. [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998. Duerst, et al. Expires September 7, 2006 [Page 14]
Internet-Draft The 'mailto' URI Scheme March 2006 Authors' Addresses Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever possible, for example as "Dürst" in XML and HTML.) Aoyama Gakuin University 5-10-1 Fuchinobe Sagamihara, Kanagawa 229-8558 Japan Phone: +81 42 759 6329 Fax: +81 42 759 6495 Email: mailto:duerst@it.aoyama.ac.jp URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/ Larry Masinter Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA Phone: +1-408-536-3024 Email: LMM@acm.org URI: http://larry.masinter.net/ Jamie Zawinski DNA Lounge 375 Eleventh Street San Francisco, CA 94103 USA Email: jwz@jwz.org Duerst, et al. Expires September 7, 2006 [Page 15]
Internet-Draft The 'mailto' URI Scheme March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Duerst, et al. Expires September 7, 2006 [Page 16]
