]>

1770 Massachusetts Ave, Ste 322 Cambridge MA 02140 USA +1 617 491 5735 john-ietf@jck.com

76, Ylang Ylang Avenue Quatre Bornes Mauritius sm+ietf@elandsys.com

Applications IETF While the URI specification has been widely deployed, it has long been recognized that many valid URIs, especially those that contain extensive information in the "tail" are unsuitable for user presentation, especially for internationalized environments. IRIs have been proposed as a solution for that problem but inherit (and are constrained by) the complex and sometimes method-dependent syntax model of URIs as well as positional and ordering assumptions that make them more difficult to localize than is desirable. This specification illustrates a way to define an "above URI" model for a localization-friendly simple reference identifier (SRI) that explicitly identifies fields and is more appropriate than IRIs to support localization. The current version is intended simply to initiate a discussion. In particular, while it is written to use an XML element syntax model, variations using JSON or some other system with explicitly-labeled data fields might be as, or more, appropriate.

While the URI specification has been widely deployed, it has long been recognized that many valid URIs, especially those that contain extensive information in the "tail" are unsuitable for user presentation, especially for internationalized environments. IRIs have been proposed as a solution for that problem but inherit (and are constrained by) the complex and sometimes method-dependent syntax model of URIs as well as positional and ordering assumptions that make them more difficult to localize than is desirable. This specification illustrates a way to define a localization-friendly "above URI" simple syntax (a "SRI") that explicitly identifies fields and is more appropriate than IRIs to support localization. Note in Draft: "Simple" is chosen in the grand tradition of "simple" protocols like SMTP and SIP". Certainly the parsing of the compound identifier into components is simpler than the URI model. But suggestions for alternate terms would be welcome if "simple" turns into flame-bait. This specification obviates most, if not all, of the perceived need for IRIs and hence obsoletes the specification of them in RFC 3087. A discussion of the reasons for that action appears in .

The terms "i18n" and "l10n" are liberally used as abbreviations for "internationalization" and "localization", respectively, in this specification. 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 RFC 2119.

RFC Editor: Please remove this subsection. This draft is a pre-proposal to stimulate discussion of the IRI approach and alternatives to it. While it is deliberately incomplete, the path to an actual proposal should be clear. Also, the choice of an XML element syntax model structure was fairly arbitrary. It would probably be equally reasonable to support a JSON or other structure instead (or additionally) as long as the basic syntax chosen supports clear identification of data elements and a very precise and context-independent syntax for element values. Discussion of this draft should occur on the IRI WG mailing list. Details about subscription and archives for the list may be found at XXXXX.

Much of the complexity in the URI specification lies in trying to identify and extract the various parts of a URI. That process is complicated by scheme-dependent elements and the associated delimiters which may be reserved or not depending on the scheme. That work may be appropriate if some system actually needs to parse and execute a URI -- an activity that requires understanding the scheme in any event-- but may be less appropriate for an i18n / l10n overlay. This specification overcomes that problem and the associated complexities introduced by characters outside the ASCII repertoire, URI escaping conventions, and so on by eliminating the constraint of forward compatibility with URIs in favor of a more international format that can be easily localized and equally easily be mapped into that URI syntax.

This section maps the various components of URIs into XML elements. For purposes of this specification, the URI syntax is discarded; only the data elements are retained. The mapping from an XML-structured document using these elements to URI syntax should be fairly obvious ...and possibly covered in more detail in a future version of this spec. It is obviously possible to specify a collection of elements with this specification that, when mapped back into URI syntax, will be invalid or confusing for a particular scheme. If that is perceived as an issue, specific lists of what elements are valid for which schemes should be easy to compile. The basic structure starts with a localization-friendly element that contains all other elements (and has no direct textual content): <SRI> Note in Draft: Each of the subsections that follow can probably benefit from some fleshing-out. For this version, the general intent should be clear. It is likely that several more subsidiary elements are needed, but that is a topic for future discussion.

<scheme> SchemeName </scheme> The Scheme element has no subsidiary elements.

<authority> Authority elements as below. </authority> The Authority element has the subsidiary elements listed in the subsections below.

Domain names are subject to special rules because of IDNA considerations, so the normal content of the host element is a domain element. [Domain-]relative URIs do not use the domain element.

<domain> Fully-qualified-domain-name </domain>

<port> NN <port> NN is a numeric port number.

<path> PathString </path> Subsidiary elements here, including <domain> and/or <SRI> when appropriate.

<query> QueryString </query> Subsidiary elements here, including <domain> and/or <SRI> when appropriate.

<fragment> FragmentName or other identifier </fragment> The Fragment element has no subsidiary elements.

Part of the goal for the format specified here is to express the abstract components of a URI as naturally as possible. Consequently, any text component of any element can be expressed in UTF-8 in normalization form NFC. Escapes ("%" or otherwise) are prohibited except as required by XML. If "%" appears, it must be doubled in mapping to URI syntax.

There should be several of these, each showing a URI and the matching XRI form. The URI that would appear as http://example.com/test?sri=http://example.net/ Would appear in this form as:

<uri> <sri> <scheme>http</scheme> <authority> <host> <domain>example.com</domain> </host> </authority> <path>/test</path> <query> <sri> <scheme>http</scheme> <authority> <host> <domain>example.net</domain> </host> </authority> </sri> </query> </sri> </uri>

Note in draft: RFC (and I-D) constraints prohibit showing one of these data structures with characters in it outside the ASCII repertoire. If the document ever progresses to RFC, an alternate form that can show such examples including such characters should be a requirement.

Some of the structuring information for this document was derived from a W3C working draft on URLs as well as the URI specification. The thinking that led to this work started with a discussion many years ago with James Seng in which he pointed out that the "natural" ordering of components of compound identifiers differed by culture.

RFC Editor: Please remove this section before publication. This memo includes no requests to or actions for IANA.

The model introduced in this specification does not raise any security issues not already present in the URI specification that would not be caught by a URI processor. Because it is less subtle and complex than the URI specification, it may actually lead to a reduction in vunerabilities.

&rfc2119; &rfc3986; &rfc3987;

&rfc4627; &rfc3490; &rfc5890; &rfc6055; IETF

W3C

The original IRI specification was intended as a strict superset of the URI syntax with all URI forms being permitted but with the use of non-escaped UTF-8 strings also being allowed. IRIs were not separate protocol identifiers or intended for use "on the wire". Instead, they were intended as an overlay for URIs that was more convenient for users. In part because of the interaction with the original and revised versions of the IDNA specification, the mapping from IRIs to URIs was not unique: one could map a domain name expressed as a UTF-8 string into either a URI escape sequence or into a set of IDNA A-labels. That choice interacted badly with the domain name encoding considerations discussed by the IAB and, more importantly, with URI comparisons in caches and similar contexts. Based on those and other considerations, an IETF WG charged with IRI revision concluded that IRIs should be treated as a separate protocol identifier, primarily for use in new protocols, rather than as a strictly-forward-compatible URI overlay. That decision immediately raised the question of whether it was more valuable to preserve a URI-like syntax or depart from it entirely. This specification resulted from the desire to explore the possibilities that would be opened up by abandoning the constraint of apparent similarity to the URI syntax. But, just as the decision to move to a separate protocol identifier essentially recognizes that the IRIs defined in RFC 3987 was not feasible and an IRI variation that defined a new protocol element while retaining the general form of the URI syntax would obsolete 3987, this specification does as well: whether the underlying syntax model is changed or not, the WG has concluded that IRIs as defined in RFC 3987 are inappropriate for general use on the public Internet.

<!ELEMENT uri (sri)> <!-- Simple Resource Identifier --> <!ELEMENT sri (scheme, authority, path?, query?, fragment?)> <!ELEMENT authority ( user-info?, host, port?)> <!ELEMENT scheme (#PCDATA)> <!ELEMENT user-info (#PCDATA)> <!ELEMENT host (domain | ip-address)> <!ELEMENT port ((#PCDATA)> <!ELEMENT path (#PCDATA | domain | sri)*> <!ELEMENT query (#PCDATA | domain | sri)*> <!ELEMENT fragment (#PCDATA)*> <!-- This contains a FQDN --> <!ELEMENT domain (#PCDATA)> <!ELEMENT ip-address (#PCDATA)>