| Network Working Group | M.J. Duerst |
| Internet-Draft | Aoyama Gakuin University |
| Obsoletes: 6068 (if approved) | L. Masinter |
| Intended status: Standards Track | Adobe Systems Incorporated |
| Expires: March 03, 2013 | J. Zawinski |
| DNA Lounge | |
| September 2012 |
The 'mailto' URI/IRI Scheme
draft-duerst-eai-mailto-04
This document defines the format of Uniform Resource Identifiers (URIs) and Internationalized Resource Identfiers (IRIs) to identify resources that are reached using Internet mail. It adds the possibility to use Email Address Internationalization (EAI) email addresses (RFC6530) to the previous syntax of 'mailto' URIs (RFC 6068).
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.
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."
This Internet-Draft will expire on March 03, 2013.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
The 'mailto' URI/IRI scheme is a URI/IRI scheme [RFC4395bis] used to identify resources that are reached using Internet mail. In its simplest form, a 'mailto' URI/IRI contains an Internet mail address. For interactions that require message headers or message bodies to be specified, the 'mailto' URI/IRI scheme also allows providing mail header fields and a message body.
This specification extends the previous scheme definition ([RFC6068]) to also allow non-ASCII characters in the left-hand sides (LHSs) of email addresses. To work seamlessly with Internationalized Resource Identfiers (IRIs, [RFC3987]) and Email Address Internationalization (EAI, [RFC6530]), these LHSs are percent-encoded based on UTF-8 [STD63] when used in URIs.
This document is available in (line-printer ready) plaintext ASCII and PDF. It is also available in HTML from http://www.sw.it.aoyama.ac.jp/2012/pub/draft-duerst-eai-mailto-04.html, and in UTF-8 plaintext from http://www.sw.it.aoyama.ac.jp/2012/pub/draft-ietf-duerst-eai-mailto-04.utf8.txt. While all these versions are identical in their technical content, the HTML, PDF, and UTF-8 plaintext versions show non-Unicode characters directly. This often makes it easier to understand examples, and readers are therefore advised to consult these versions in preference or as a supplement to the ASCII version.
Example URIs and IRIs are enclosed in '<' and '>' as described in Appendix C of [STD66]. Extra whitespace and line breaks are added to present long URIs -- they are not part of the actual URI.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The syntax of a 'mailto' URI is described using the ABNF of [STD68]. The syntax of a 'mailto' IRI can be obtained from this definition by allowing <iunreserved> characters wherever <unreserved> characters are allowed. The syntax below also uses non-terminal definitions from [STD66] (unreserved, pct-encoded):
mailtoURI = "mailto:" [ to ] [ hfields ]
to = addr-spec-enc *("," addr-spec-enc )
hfields = "?" hfield *( "&" hfield )
hfield = hfname "=" hfvalue
hfname = *qchar
hfvalue = *qchar
addr-spec-enc = local-part-enc "@" domain-enc
local-part-enc = dot-atom-text-enc / quoted-string-enc
domain-enc = dot-atom-text-enc / "[" *dtext-no-obs "]"
dtext-no-obs = %d33-90 ; Printable US-ASCII
/ %d94-126 ; characters not including
; "[", "]", or "\"
dot-atom-text-enc = <percent-encoded version of
dot-atom-text or its EAI equivalent>
quoted-string-enc = <percent-encoded version of
dot-atom-text or its EAI equivalent>
qchar = unreserved / pct-encoded / some-delims
some-delims = "!" / "$" / "'" / "(" / ")" / "*"
/ "+" / "," / ";" / ":" / "@" / "/" / "?"
In addition to the above syntax rules, the details given in the next two subsections are relevant.
<addr-spec-enc> is a mail address as specified by <addr-spec> in [RFC5322] or <uAddr-Spec> in [RFC6532], but excluding <comment>, with the following changes:
<dot-atom-text-enc> is the percent-encoded version of <dot-atom-text> in [RFC5322] or <uDot-Atom-text> in [RFC6532]. <quoted-string-enc> is the percent-encoded version of <quoted-string> in [RFC5322] or <uQuoted-String> in [RFC6532].
<hfname> and <hfvalue> are encodings of an [RFC5322] header field name and value, respectively. Percent-encoding is needed for the same characters as listed above for <addr-spec-enc>. <hfname> is case-insensitive, but <hfvalue> in general is case-sensitive. Note that [RFC5322] allows all US-ASCII printable characters except ":" in optional header field names (Section 3.6.8), which is the reason why <pct-encoded> is part of the header field name production.
The special <hfname> "body" indicates that the associated <hfvalue> is the body of the message. The "body" field value is intended to contain the content for the first text/plain body part of the message. The "body" pseudo header field is primarily intended for the generation of short text messages for automatic processing (such as "subscribe" messages for mailing lists), not for general MIME bodies. Except for the encoding of characters based on UTF-8 and percent-encoding, no additional encoding (such as e.g., base64 or quoted-printable; see [RFC2045]) is used for the "body" field value. As a consequence, header fields related to message encoding (e.g., Content-Transfer-Encoding) in a 'mailto' URI are irrelevant and MUST be ignored. The "body" pseudo header field name has been registered with IANA for this special purpose (see Section 8.2).
Within 'mailto' URIs, the characters "?", "=", and "&" are reserved, serving as delimiters. They have to be escaped (as "%3F", "%3D", and "%26", respectively) when not serving as delimiters.
Additional restrictions on what characters are allowed might apply depending on the context where the URI is used. Such restrictions can be addressed by context-specific escaping mechanisms. For example, because the "&" (ampersand) character is reserved in HTML and XML, any 'mailto' URI that contains an ampersand has to be written with an HTML/XML entity ("&") or numeric character reference ("&" or "&").
Non-ASCII characters can be encoded in <hfvalue> as follows:
Note that it is syntactically valid to specify both <to> and an <hfname> whose value is "to". That is,
<mailto:addr1@an.example,addr2@an.example>
is equivalent to
<mailto:?to=addr1@an.example,addr2@an.example>
is equivalent to
<mailto:addr1@an.example?to=addr2@an.example>
However, the latter two forms are NOT RECOMMENDED because different user agents handle this case differently. In particular, some existing clients ignore "to" <hfvalue>s.
Implementations MUST NOT produce two "To:" header fields in a message; the "To:" header field may occur at most once in a message ([RFC5322], Section 3.6). Also, creators of 'mailto' URIs MUST NOT include other message header fields multiple times if these header fields can only be used once in a message.
To avoid interoperability problems, creators of 'mailto' URIs SHOULD NOT use the same <hfname> multiple times in the same URI. If the same <hfname> appears multiple times in a URI, behavior varies widely for different user agents, and for each <hfname>. Examples include using only the first or last <hfname>/<hfvalue> pair, creating multiple header fields, and combining each <hfvalue> by simple concatenation or in a way appropriate for the corresponding header field.
Note that this specification, like any URI/IRI scheme specification, does not define syntax or meaning of a fragment identifier (see [STD66]), because these depend on the type of a retrieved representation. In the currently known usage scenarios, a 'mailto' URI cannot be used to retrieve such representations. The character "#" in <hfvalue>s MUST be escaped as %23.
A 'mailto' URI/IRI designates an "Internet resource", which is the mailbox specified in the address. When additional header fields are supplied, the resource designated is the same address but with an additional 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.
The operation of how any URI/IRI scheme is resolved is not mandated by the URI specifications. In current practice, resolving URIs/IRIs such as those in the 'http' URI/IRI scheme causes an immediate interaction between client software and a host running an interactive server. The 'mailto' URI/IRI has unusual semantics because resolving such a URI/IRI does not necessarily cause an immediate interaction with a server. 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 the message unedited, or choose not to send the message.
Note that with the introduction of the possibility to register handlers of URI/IRI schemes to web applications, there is no longer a guarantee that the resolution of a 'mailto' URI/IRI is purely local. Registering a web mail service as a handler of 'mailto' URIs/IRIs means that the creation of a message to the designated address is done with the help and knowledge of that web mail service.
The <hfname>/<hfvalue> pairs in a 'mailto' URI/IRI, although syntactically equivalent to header fields in a mail message, do not directly correspond to the header fields in a mail message. In particular, the To, Cc, and Bcc <hfvalue>s don't necessarily result in a header field containing the specified value. Mail client software MAY eliminate duplicate addresses. Creators of 'mailto' URIs SHOULD avoid using the same address twice in a 'mailto' URI/IRI.
Originator fields like From and Date, fields related to routing (Apparently-To, Resent-*, etc.), trace fields, and MIME header fields (MIME-Version, Content-*), when present in the URI/IRI, MUST be ignored. The mail client MUST create new fields when necessary, as it would for any new message. Unrecognized header fields and header fields with values inconsistent with those the mail client would normally send SHOULD be treated as especially suspect. For example, there may be header fields that are totally safe but not known to the MUA, so the MUA MAY choose to show them to the user.
The user agent interpreting a 'mailto' URI/IRI SHOULD NOT create a message if any of the header fields are considered dangerous; it MAY also choose to create a message with only a subset of the header fields given in the URI/IRI. Only a limited set of header fields such as Subject and Keywords, as well as Body, are believed to be both safe and useful in the general case. In cases where the source of a URI/IRI is well known, and/or specific header fields are limited to specific well-known values, other header fields MAY be considered safe, too.
The creator of a 'mailto' URI/IRI cannot expect the resolver of a URI/IRI to understand more than the "subject" header field and "body". Clients that resolve 'mailto' URIs/IRIs into mail messages MUST be able to correctly create [RFC5322]-compliant mail messages using the "subject" header field and "body".
[STD66] requires that many characters in URIs/IRIs be encoded. This affects the 'mailto' URI/IRI scheme for some common characters that might appear in addresses, header fields, 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". Implementations MAY add a final line break to the body of a message even if there is no trailing "%0D%0A" in the body <hfield> of the 'mailto' URI/IRI. Line breaks in other <hfield>s SHOULD NOT be used.
When creating 'mailto' URIs/IRIs, any reserved characters that are used in the URIs/IRIs MUST be encoded so that properly written URI/IRI interpreters can read them. Also, client software that reads URIs/IRIs MUST decode strings before creating the mail message so that the mail message appears in a form that the recipient software will understand. These strings SHOULD be decoded before showing the message to the sending user.
Software creating 'mailto' URIs/IRIs likewise has to be careful to encode any reserved characters that are used. HTML forms are one kind of software that creates 'mailto' URIs/IRIs. Current implementations encode a space as '+', but this creates problems because such a '+' standing for a space cannot be distinguished from a real '+' in a 'mailto' URI/IRI. When producing 'mailto' URIs/IRIs, all spaces SHOULD be encoded as %20, and '+' characters MAY be encoded as %2B. Please note that '+' characters are frequently used as part of an email address to indicate a subaddress, as for example in <bill+ietf@example.org>.
The 'mailto' URI/IRI scheme is limited in that it does not provide for substitution of variables. Thus, it is impossible to create a 'mailto' URI/IRI that includes a user's email address in the message body. This limitation also prevents 'mailto' URIs/IRIs that are signed with public keys and other such variable information.
To represent characters outside US-ASCII in a document format that is limited to US-ASCII, this document uses 'XML Notation'. A non-ASCII character is denoted by a leading '&#x', a trailing ';', and the hexadecimal number of the character in the UCS in between. For example, Я stands for CYRILLIC CAPITAL LETTER YA
Where the IRI form of an example is identical to the URI form, only one form is given. If the IRI form is different, then both forms are given.
A URI for an ordinary individual mailing address:
<mailto:chris@example.com>
A URI for a mail response system that requires the name of the file to be sent back 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, with 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 occurs when browsing archives of messages. A link can be provided that allows replying to a message and conserving threading information. This is done by adding an In-Reply-To header field 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>
A request to subscribe to a mailing list:
<mailto:majordomo@example.com?body=subscribe%20bamboo-l>
A URI that is for a single user and that 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, using "?" twice, is incorrect:
<mailto:joe@example.com?cc=bob@example.com?body=hello> ; WRONG!
According to [RFC5322], the characters "?", "&", and even "%" may occur in <addr-spec>s. The fact that they are reserved characters 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 use:
<mailto:gorby%25kremvax@example.com>
To indicate the address "unlikely?address@example.com", and include another header field, one would use:
<mailto:unlikely%3Faddress@example.com?blat=foop>
As described above, the "&" (ampersand) character is reserved in HTML and has to be replaced, e.g., with "&". Thus, in an HTML context 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.
When an email address itself includes an "&" (ampersand) character, that character has to be percent-encoded. For example, the 'mailto' URI to send mail to "Mike&family@example.org" is <mailto:Mike%26family@example.org>.
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>.
Email address: "\\\"it's\ ugly\\\""@example.org; corresponding 'mailto' URI:
<mailto:%22%5C%5C%5C%22it's%5C%20ugly%5C%5C%5C%22%22@example.org>.
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, as an URI:
<mailto:user@example.org?subject=caf%C3%A9>
The same as an IRI:
<mailto:user@example.org?subject=caf
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, as an URI:
<mailto:user@example.org?subject=caf%C3%A9&body=caf%C3%A9>
The same as an IRI:
<mailto:user@example.org?subject=caf
This 'mailto' URI may result in an [RFC5322] 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
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.
In a context where EAI is supported, this 'mailto' URI can result in an [RFC6532] message looking like this (encoded as UTF-8 on the wire):
From: sender@example.net To: user@example.org Subject: caf
For more examples of encoding the word coffee in different languages, see [RFC2324].
The following example uses the Japanese word "natto" (Unicode characters U+7D0D U+8C46, as an URI:
<mailto:user@%E7%B4%8D%E8%B1%86.example.org?subject=Test&body=%E7%B4%8D%E8%B1%86>
The same as an IRI:
<mailto:user@
When constructing the email for use with [RFC5322], the domain name label is converted to punycode. The resulting message might look as follows:
From: sender@example.net To: user@xn--99zt52a.example.org Subject: Test Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: base64 57SN6LGG
The same message using EAI ([RFC6532]) can look as follows (encoded as UTF-8 on the wire):
From: sender@example.net To: user@
All the previous 'mailto' URIs can be used with EAI. When used with EAI, there is no need to use punycode in domain names, and no need to use MIME encoding in headers and bodies. After decoding percent-encoding, UTF-8 can be used directly. This subsection gives a few additional examples of 'mailto' URI and IRIs which can only be used with EAI.
Please note that the choice of URI vs. IRI is independent of whether EAI can be used or not.
A hypothetical 'mailto' URI for ordering coffee from a French coffee pot:
mailto:caf%C3%A9@pot.example?Subject=Espresso,%20please
The same as an IRI:
mailto:caf
A hypothetical 'mailto' URI for sending a potential erratum to the first author of this memo ("%C3%BC" represents an u-umlaut, "%E9%9D%92%E5%B1%B1" represents the Unicode characters U+9752 (blue) and U+5C71 (mountain)):
mailto:Martin.D%C3%BCrst@%E9%9D%92%E5%B1%B1.example.net?Subject=Error%20in%20RFC6068bis
The same as an IRI:
mailto:Martin.D
The 'mailto' URI/IRI 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 encrypted, they can also be read at any of those sites.
Also, if a web mail service is registered as a handler of 'mailto' URIs/IRIs, this means that the creation of a message to the designated address is done with the knowledge of that web mail service, even if the message is actually never sent.
A 'mailto' URI/IRI 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/IRI, as well as being hidden in the user interface (for example, a link on an HTML Web page might display something other than the content of the corresponding 'mailto' URI/IRI that would be used when clicked). Thus, a mail client SHOULD NOT send a message based on a 'mailto' URI/IRI without first disclosing and showing to the user the full message that will be sent (including all header fields that were specified by the 'mailto' URI/IRI), 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/IRI. Users are strongly encouraged to ensure that the 'mailto' URI/IRI presented to them matches the address included in the "To:" line of the email message.
Some header fields are inherently unsafe to include in a message generated from a URI/IRI. For details, please see Section 3. In general, the fewer header fields interpreted from the URI/IRI, the less likely it is that a sending agent will create an unsafe message.
Examples of problems with sending unapproved mail include:
Programs that interpret 'mailto' URIs/IRIs SHOULD ensure that the SMTP envelope return path address, which is given as an argument to the SMTP MAIL FROM command, is set and correct, and that the resulting email is a complete, workable message.
'mailto' URIs/IRIs on public Web pages expose mail addresses for harvesting. This applies to all mail addresses that are part of the 'mailto' URI/IRI, including the addresses in a "bcc" <hfvalue>. Those addresses will not be sent to the recipients in the 'to' field and in the "to" and "cc" <hfvalue>s, but will still be publicly visible in the URI/IRI. Addresses in a "bcc" <hfvalue> may also leak to other addresses in the same <hfvalue> or become known otherwise, depending on the mail user agent used.
Programs manipulating 'mailto' URIs/IRIs have to take great care to not inadvertently double-escape or double-unescape 'mailto' URIs/IRIs, and to make sure that escaping and unescaping conventions relating to URIs/IRIs and relating to mail addresses are applied in the right order.
Implementations parsing 'mailto' URIs/IRIs must take care to sanity check 'mailto' URIs/IRIs in order to avoid buffer overflows and problems resulting from them (e.g., execution of code specified by the attacker).
The security considerations for URIs ([STD66]), IRIs ([RFC3987]), IDNA ([RFC5890] and [RFC5891]), and EAI ([RFC6530] and [RFC6532]) also apply. Implementers and users are advised to check them carefully.
This document changes the definition of the 'mailto' URI/IRI scheme; the registry of URI/IRI schemes should be updated to refer to this document rather than its predecessor [RFC6068]. The registration template is as follows:
Resource Identifier (RI) Scheme name:
'mailto'
Status:
permanent
Scheme syntax:
See the syntax section of RFC YYYY.
[RFC Editor: Please replace with actual RFC number.]
Scheme semantics:
See the semantics section of RFC YYYY.
[RFC Editor: Please replace with actual RFC number.]
Encoding considerations:
See the syntax and encoding sections of RFC YYYY.
[RFC Editor: Please replace with actual RFC number.]
Applications/protocols that use this scheme name:
The 'mailto' URI/IRI scheme is widely used since
the start of the Web.
Interoperability considerations:
Interoperability for 'mailto' URIs/IRIs with UTF-8-based
percent-encoding might be somewhat lower than interoperability
for 'mailto' URIs with US-ASCII only. In particular,
interoperability for 'mailto' URIs/IRIs with UTF-8-based
percent-encoding in the LHS of email addresses requires
support of EAI [RFC6530].
Security considerations:
See the security considerations section of RFC YYYY.
[RFC Editor: Please replace with actual RFC number.]
Contact:
IETF
Author/Change controller:
IETF
References:
IANA is herewith requested to update the reference for the registration of the Body header field in the Message Header Fields Registry ([RFC3864]) from [RFC6068] to this document (there are no changes to the specification of the Body header field itself).
The main changes from [RFC6068] are as follows:
RFC Editor: Please remove this section before publication.
This document was derived from [RFC6068]; the acknowledgments from that specification and its predecessor still apply.
Valuable input on this document was received from (in no particular order): Shawn Steele, Frank Ellermann, John Klensin, Yangwoo Ko
| [RFC2324] | Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, April 1998. |
| [RFC6068] | Duerst, M.J., Masinter, L. and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, October 2010. |
| [RFC6530] | Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012. |
| [RFC4395bis] | Hansen, T., Hardie, T. and L. Masinter, "Guidelines and Registration Procedures for New URI/IRI Schemes", draft draft-ietf-iri-4395bis-irireg-04, December 2011. |