| Internet Engineering Task Force | S. Ruby, Ed. |
| Internet-Draft | IBM |
| Intended status: Informational | L. Masinter |
| Expires: June 20, 2015 | Adobe |
| December 17, 2014 |
Problem Statement: URL
draft-ruby-url-problem-00
This document lays out the problem space of possibly conflicting standards between multiple organizations for URLs and things like them, and proposes some actions to resolve the conflicts. From a user or developer point of view, it makes no sense for there to be a proliferation of definitions of URL nor for there to be a proliferation of incompatible implementations. This shouldn't be a competitive feature. Therefore there is a need for the organizations involved to update and reconcile the various Internet Drafts, Recommendations, and Standards in this area.
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 June 20, 2015.
Copyright (c) 2014 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 section contains a very compressed history of URL standards, in sufficient detail to set some context.
The first standards-track specification for URLs was [RFC1738] in 1994. (That spec contains more background material.) It defined URLs as ASCII only. Although it was quickly determined that it was desirable to allow non-ASCII characters, shoehorning utf-8 into ASCII-only systems was unacceptable; at the time Unicode was not so widely deployed. The tack was taken to leave "URI" alone and define a new protocol element, "IRI"; [RFC3987] was published in 2005 (in sync with the [RFC3986] update to the URI definition).
The IRI-to-URI transformation specified in [RFC3987] had options; it wasn't a deterministic path. The URI-to-IRI transformation was also heuristic, since there was no guarantee that %xx-encoded bytes in the URI were actually meant to be %xx percent-hex-encoded bytes of a utf8 encoding of a Unicode string.
To address issues and to fix URL for HTML5, a new IRI working group <https://tools.ietf.org/wg/iri/charters> was established in IETF in 2009. Despite years of development, the IRI group was closed in 2014, with the consolation that the documents that were being developed in the IRI working group could be updated as individual submissions or within the "applications area" working group. In particular, one of the IRI working group items was to update [appsawg-uri-scheme-reg], which is currently under development in IETF's application area.
Independently, the HTML specifications in the WHATWG and W3C redefined "URL" in an attempt to match what some of the browsers were doing. This definition was moved out into the "URL - Living Standard" [URL-LS] .
The world has also moved on. ICANN has approved non-ASCII top level domains, but IDNA specs ([RFC3490] and [RFC5895]) did not fully addressed IRI processing. Subsequently, the Unicode consortium produced [UTS-46].
There are multiple umbrella organizations which have produced multiple documents, and it's unclear whether there's a trajectory to make them consistent. This section tries to enumerate currently active organizations and specs.
Organizations include the IETF, the WHATWG, the W3C, Web Platform.org, and the Unicode Consortium. Relevant specs under development in each organization include:
[appsawg-uri-scheme-reg] and [kerwin-file-scheme] are under active development.
The IRI working group closed, but work can continue in the Applications Area working group. Documents sitting needing update, abandoned now, are three drafts ([iri-3987bis], [iri-comparison], and [iri-bidi-guidelines]), which were originally intended to obsolete [RFC3987].
In addition, there's quite a bit of activity around URNs and library identifiers in the URN working group, including some expressions of desire to update RFC 3986 to better accomodate desired URN semantics.
The [URL-LS] is being developed as a living standard. It primarily focuses on specifying what is important for browsers. The means by which new schemes might be registered is not yet defined. This work is based on [UTS-46], and is intented to obsolete both [RFC3986] and [RFC3987].
The Web Applications Working Group, in conjuction with the W3C TAG, sporadically have been republishing the WHATWG work with no technical content differences as [W3C-URL]. There is a [url-workmode] proposal to formalize this relationship.
[WP-URL] is being developed on a develop GitHub branch based on [URL-LS]. It currently contains work that has yet to be folded back into the [URL-LS], primarily to rewrite the parser logic in a way that is more understandable and approachable. The intent is to merge this work once it is ready, and to actively work to keep the two versions in sync.
[UTS-46] defines parameterized functions for mapping domain names. [URL-LS] builds upon this work, specifying particular values to be used for these parameters.
The main problem is conflicting specifications that overlap but don't match each other.
Additionally, the following are issues that need to be resolves to make URL processing unambiguous and stable.
This problem clearly requires a cross-organizational solution, specifically:
Helpful comments and improvements to this document have come from Anne van Kesteren and Graham Klyne.
This memo currently includes no request to IANA, although an updated [appsawg-uri-scheme-reg] might add some additional requirements and information to IANA URI scheme registry to make clear that the schemes serve as URL schemes and IRI schemes as well as URI schemes.
In addition to the security exposures created when URLs work differently in different systems, all of the security considerations defined in [RFC3490], [RFC3986], [RFC3987], and [RFC5895] apply to URLs.