url-problem-statement.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- based on draft-davies-template-bare.txt -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="info" docName="draft-ruby-url-problem-01" ipr="trust200902">

  <front>
    <title>URL Problem Statement and Directions</title>

    <author fullname="Sam Ruby" initials="S.R." role="editor"
            surname="Ruby">
      <organization>IBM</organization>

      <address>
        <postal>
          <street/>
          <city>Raleigh</city>
          <region>NC</region>
          <country>USA</country>
        </postal>

        <email>rubys@intertwingly.net</email>
        <uri>http://intertwingly.net/</uri>
      </address>
    </author>

    <author fullname="Larry Masinter" initials="L.M."
            surname="Masinter">
      <organization>Adobe</organization>

      <address>
        <postal>
          <street>345 Park Ave</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95110</code>
          <country>USA</country>
        </postal>

        <email>masinter@adobe.com</email>
        <uri>http://larry.masinter.net/</uri>
      </address>
    </author>

    <date/>

    <area>Applications</area>

    <keyword>URI</keyword>
    <keyword>URL</keyword>
    <keyword>IRI</keyword>

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document lays out the problem space around
      standards 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.</t>

      <t>Possible next steps are discussed in <xref target="nextsteps"/>.</t>

      <t>Discussions have taken place on <eref
      target="mailto:public-ietf-w3c@w3.org">public-ietf-w3c@w3.org</eref>
      (<eref
      target="http://lists.w3.org/Archives/Public/public-ietf-w3c/">
      archive</eref>) and <eref
      target="apps-discuss@w3.org">public-ietf-w3c@w3.org</eref>
      (<eref
      target="http://www.ietf.org/mail-archive/web/apps-discuss/current/maillist.html">
      archive</eref>). In addition, the W3C TAG has discussed these issues in
      meetings and on their mailing list.</t>

      <t>This document, as well as a test suite, reference implementation, and 
      <xref target="WP-URL"/> are being developed at
      <eref target="https://github.com/webspecs/url"/>, including
      an issue tracker, Wiki, and related resources.
      <eref target="https://github.com/webspecs/url/pulls">Pull requests</eref>
      for edits to doocuments or tests are most welcome.
      Raising issues in <eref target="https://github.com/webspecs/url/issues">the
      GitHub tracker</eref> is also helpful.
      Comments to the editors or on those mailing lists in email
      are also welcome.
      </t>


    </section>
    <section title="Brief History of URL Standards">
      <t>This section contains a very compressed history of URL standards,
        in sufficient detail to set some context.
	REVIEWERS: history is necessarily incomplete, but please
	report incorrect or missing essential facts.
      </t>

      <t>The first standards-track specification for URLs was <xref target="RFC1738"/>
      in 1994. (That spec contains more background material.) It defined URLs
      as ASCII only.  <xref target="RFC2396"/> later separated the generic
      syntax from concrete scheme definitions which are defined in
      separate RFCs.  Many of those scheme definitions turned out not to get
      the attention that they needed.</t>

      <t>When it became clear that it was desirable to allow non-ASCII
      characters, it was widely feared that support for Unicode by ASCII-only
      systems would turn out to be problematic.  The tack was therefore taken
      to leave "URI" alone and define a new protocol element,
      "IRI".  <xref target="RFC3987"/> was published in 2005 (in sync with the
      <xref target="RFC3986"/> update to the URI definition).  This also
      turned out not to get the attention it needed.</t>

      <t>To address issues raised both in IETF and for HTML5 (see
      <xref target="problems"/> for more details), the <eref
      target="https://tools.ietf.org/wg/iri/charters">IRI working
      group</eref> was established in the IETF in 2009.  However,
      primarily due to lack of engagement, the IRI group was closed in
      2014, with the plan that the documents that had been under
      development in the IRI working group could be updated as
      individual submissions or within the IETF applications area
      working group.  In particular, one of the IRI working group
      items was to update <xref target="RFC4395"/>, which is currently
      under development in IETF's application area (see <xref
      target="appsawg-uri-scheme-reg"/>).</t>
      <!--
      Examples of feedback:
        http://lists.w3.org/Archives/Public/public-iri/2009Aug/0000.html
        http://lists.w3.org/Archives/Public/public-iri/2010Apr/0008.html
      -->

      <t>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 later moved out into the "URL Living Standard"
      <xref target="URL-LS"/>.</t>

      <t>When W3C produced <eref target="http://www.w3.org/TR/html5/">the HTML5
      recommendation</eref>, the normative
      reference to the WHATWG URL standard was a gating issue, and
      <eref target="http://www.w3.org/TR/2014/REC-html5-20141028/references.html#refsURL">an
      unusual compromised was reached</eref>, where the [URL] reference is given a descriptive
      paragraph rather than a single document reference.
      </t>

      <t>The world has moved on in other ways. ICANN has approved non-ASCII top level
      domains, but IDNA specs (<xref target="RFC3490"/> and <xref target="RFC5895"/>)
      did not fully addressed IRI processing.  Subsequently, the Unicode consortium
      produced <xref target="UTS-46"/>, which mentions URL processing in passing.</t>

      <t>The web security working group developed
      <xref target="RFC6454"/> ("The Web Origin Concept"), which 
      was refined in the W3C <xref target="CORS"/> specification,
      which <xref target="URL-LS"/> redefines.  Updates
      in the IETF were abandoned.  Work continues in the WHATWG in
      the <xref target="FETCH"/> specification.
      </t>

    </section>

    <section title="Current Organizations and Specs in Development">
      <t>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.
      REVIEWERS: are there important ongoing activities we've missed
      or gotten wrong? Who are the stakeholders whose current
      work might be affected? (This input will help determine the
      organizational coordination needed.)
      </t>
      <t>Organizations include
      the <eref target="https://www.ietf.org/about/">IETF</eref>,
      the <eref target="https://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F">WHATWG</eref>, 
      the <eref target="http://www.w3.org/Consortium/">W3C</eref>,
      <eref target="https://specs.webplatform.org/docs/">Web
      Platform.org</eref>, and
      the <eref target="http://www.unicode.org/consortium/consort.html">Unicode
      Consortium</eref>.
      Relevant specs under development in each organization include:</t>

      <section title="IETF">
        <t><xref target="appsawg-uri-scheme-reg"/> has
	passed working group last call and entered IESG 
	review.</t>

	<t>New schemes and updates to old ones continue, including 
	'file:' <xref target="kerwin-file-scheme"/> 
	and 'urn:'. </t>

        <t>The IRI working group closed, but work can continue in the Applications
        Area working group. Documents sitting needing update, abandoned now,
        are three drafts (<xref target="iri-3987bis"/>, 
        <xref target="iri-comparison"/>, and
        <xref target="iri-bidi-guidelines"/>), which were
        originally intended to obsolete <xref target="RFC3987"/>.</t>
	
	<t>The <eref target="http://datatracker.ietf.org/wg/urnbis/charter/">URNBis
	working group</eref> has been working to update the definitions
	of URNs, but has difficulty with some of the wording in
        <xref target="RFC3986"/>.  In particular, 
        <eref target="http://datatracker.ietf.org/doc/draft-ietf-urnbis-semantics-clarif/"/>
        updates <xref target="RFC3986"/>.
        </t>
      </section>

      <section title="WHATWG">
        <t>The <xref target="URL-LS"/> is being developed as a <eref
        target="https://wiki.whatwg.org/wiki/FAQ#What_does_.22Living_Standard.22_mean.3F">living
        standard</eref>.  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 <xref target="UTS-46"/>, and includes an explicit goal of
        obsoleting both <xref target="RFC3986"/> and <xref
        target="RFC3987"/>.</t>
      </section>

      <section title="W3C">
        <t>The <eref target="http://www.w3.org/2014/06/webapps-charter.html">Web 
        Applications Working Group</eref>, in conjunction with the 
        <eref target="http://www.w3.org/2001/tag/">TAG</eref>,
        sporadically have been republishing the WHATWG work with no
        technical content differences as <xref target="W3C-URL"/>.  There is a
        <xref target="url-workmode"/> proposal to formalize this
        relationship.</t>

	<t>The W3C <eref target="http://www.w3.org/2001/tag/">TAG</eref>
        developed
	<eref target="http://www.w3.org/TR/fragid-best-practices/">
	  Best Practices for Fragment Identifiers and Media Type Definitions
	</eref>, which points out several problems with the definitions
	for the 'fragment' part of URLs.  The TAG is working to
	ensure liaison exchange happens.</t>
	
	<t>Note also the interim solution for <eref
	target="http://www.w3.org/TR/2014/REC-html5-20141028/references.html#refsURL">the
	HTML5 reference to [URL]</eref>, which should be updated by
	<eref target="http://www.w3.org/html/wg/">the HTML working
	group </eref>.</t>

      </section>

      <section title="WebPlatform">
        <t>WebPlatform.org is an activity sponsored by <eref 
	target="http://www.webplatform.org">W3C and web vendors</eref>.
	<xref target="WP-URL"/> is being developed on a
        <eref target="https://specs.webplatform.org/#how">develop</eref>
        GitHub branch based on <xref target="URL-LS"/>.  It
        currently contains work that has yet to be folded back into the
        <xref target="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.</t>
      </section>

      <section title="Unicode Consortium">
        <t><xref target="UTS-46"/> defines parameterized functions for mapping
        domain names.  <xref target="URL-LS"/> builds upon this work, specifying
        particular values to be used for these parameters.  The Unicode
        Consortium plans to adapt <xref target="UTS-46"/> as registries (e.g.
        DENIC) move from <xref target="RFC3490"/> to 
        <xref target="RFC5895"/>.</t>
      </section>
    </section>

    <section anchor="problems" title="Problem Statements">
      <t>This section lays out the problems we see need a coordinated
       solution. REVIEWERS: have we missed some things? Are any of these
       non-problems or not worth solving? </t>

       <t>The main problem is conflicting specifications that overlap
       but don't match each other.</t>
       <t>Additionally, the following are issues that need to be resolved to
       make URL processing unambiguous and stable.</t>
       
      <t><list style="symbols">
        <t>Nomenclature: over the years, a number of different sets of
        terminology has been used.  URL / URI / IRI is not the only difference.
        <xref target="tantek-slice"/> chronicles a number of differences.</t>
	
	<t>Deterministic parsing and transformation: The IRI-to-URI
	transformation specified in <xref target="RFC3987"/> had
	options; it wasn't a deterministic path; in particular, which
	substrings of which URLs of which Unicode, for strings were to
	be transformed to Punycode or to %-escaped-utf8.  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 UTF-8 encoding
	of a Unicode string.</t>
      
        <t>Parameterization: standards in this area need to define such
        matters as normalization forms and values for parameters such as
        UseSTD3ASCIIRules.</t>

        <t>Interoperability: even after accounting for the above, there
        is a demonstrable lack of interoperability across popular libraries
        and browsers.  <xref target="whatwg-interop"/> identifies a number
        of such differences.</t>

	<t>Stability: Before any standard document can be marked as obsoleted,
	the requirements other specs that normatively reference the
	to-be-obsoleted standard need to be considered, to avoid
	dangling references.
	</t>
      
	<t>IDNA: <xref target="RFC3490"/> defines processing for 'IDN-aware
	domain name slots' (where "the host portion of the URI in the
	src attribute of an HTML &lt;IMG&gt; tag" is given as an
	example. Later, "IDNA is applicable to all domain names in all
	domain name slots". So in mailto:user@host, is the host a
	IDN-aware domain name slot? A domain name slot at all?  </t>

	<t>Bidi URLs: The problems with writing URLs using characters
        from right-to-left languages are well-known among experts; what is not
        known is a solution for these problems.  The solution given in 
        <xref target="RFC3987"/> has some obvious errors (how to handle
        combining marks); it's general approach also probably can be improved
        on, but it's not sure how.</t>

        <t>Specific scheme definitions: some UR* scheme definitions are woefully
          out of date, incomplete, or don't correspond to current practice,
          but updating their definitions is unclear. This includes 'file:',
          for which there is a current effort, but there are others which
          need review (including 'ftp:', 'data:').
        </t>
      </list></t>
    </section>

    <section anchor="nextsteps" title="Next Steps, Solutions">
      
      <t>Many of the problem above require some cross-organizational
      collaboration.  This section outlines alternatives and possible
      next steps, both in terms of documents and possible updates and
      also procedural issues.</t>

      <t>REVIEWERS: Neccessary? Sufficient? What are we missing, what
      did we get wrong?</t>

      <section title="Working Groups and Discussion Venues">
        <t>The <eref target="http://www.w3.org/Signature/">XML Signature
        WG</eref> is an example of a joint IETF/W3C Working Group.  Perhaps a
        joint working group covering the topics of URL and URI could be
        formed.  Elements of the <xref target="url-workmode"/> proposal could
        be incorporated into the charter of this new WG, and thereby
        establishing the WHATWG as a third joint participant in this
        activity.</t>

        <t>Failing that, it may be desirable to have some organizational
        assignment of responsibility in IETF and W3C to working groups in each
	organization.</t>
	
	<t>There has been discussion of IETF/W3C liaison getting
	involved, with the proposal that W3C liaison to IETF
	making a formal liaison request to which IETF would respond.
	Perhaps the liaison request might reference this document. </t>

	<t>In IETF, the scope of changes proposed may determine how
	IETF consensus can best be obtained.  It seems unlikely that
	the scope of necessary changes to IETF documents could be
	managed through individual submissions. Some opinions have
	been that updating <xref target="RFC3986"/> and/or obsoleting 
        <xref target="RFC3987"/> would
	require a full IETF working group.  Unless and until another
	group is chartered (perhaps using this document as the Problem
	Statement / scope), discussion is occuring in the IETF apps area.
        Previous venues for
	related topics (
        <eref target="https://lists.w3.org/Archives/Public/public-iri/">public-iri@w3.org</eref>,
        <eref target="https://lists.w3.org/Archives/Public/uri/">uri@w3.org</eref>)
        are old enough that there is likely poor representation of
	important communities, unless a concerted effort is made
	to revive them.</t>

	<t>In W3C, either W3C WebApps, TAG, HTML or some new activity
	might be necessary to manage changes, but the nature of the
	group necessary to review depends on the extent of changes
	needed. </t>

	<t>At the moment, the most reliable way of giving feedback on
	this document is to raise or comment on issues in <eref
	target="https://github.com/webspecs/url/issues">the GitHub
	issue list</eref>.</t>

      </section>

      <section title="Leave, Update or Obsolete RFC 3986 (URI)">
	<t>At various times, many have called for replacing the IETF
	URI standard <xref target="RFC3986"/>, or updating it. How to
	approach this is controversal, but at a minimum the following
	are needed:

	<list style="symbols">
          <t>Make it clear that ASCII-only URIs (as now defined by
          <xref target="RFC3986"/>) are not what is mainly used on the web.</t>
	  <t>Incorporate updates for URN.</t>
	  <t>Incorporate updates for fragment identifier semantics.</t>
	  <t>Note terminology issue and resolution.</t>
	</list>
	</t>
	<t>More controversial is whether this can be done on a
	strictly "need-to" basis, or whether the merger of URI from
        <xref target="RFC3986"/> and IRI from <xref target="RFC3987"/> would
        result in clearer specifications for implementors.</t>
      </section>

      <section title="Obsolete RFC 3987 (IRI)"> 

	<t>There is some sentiment to restart the work of updating
        <xref target="RFC3987"/> by starting again, fixing errors and
        integrating errata. However, this path doesn't seem to satisfy the
        desire for a single spec that lays out deterministic processing for
        URLs and references for browser and operating-system handling
	of both.</t>

	<t>After ensuring that topics covered in <xref
	target="RFC3987"/> are also covered by a W3C URL
	recommendation, mark <xref target="RFC3987"/> as obsolete
	with a short RFC noting the conditions laid out in this
	document.
	</t>
      </section>

      <section title="Obsolete RFC 6454 (Origin)">
	<t>
	  Replaced by <xref target="CORS"/>, <xref target="URL-LS"/>, and/or
          <xref target="FETCH"/>.
	</t>
      </section>
      <section title="file: URI scheme">
	<t> 
	  Coordinate 'file:' syntax in <xref target="URL-LS"/>
	  and <xref target="kerwin-file-scheme"/>, possibly
	  moving the 'file:' part of URL-LS into a separate
	  document.
	</t>
      </section>
      <section title="Other actions">
	
	<t><list style="symbols">
          <t>Update <xref target="RFC5895"/> to be consistent with
          <xref target="URL-LS"/> and <xref target="UTS-46"/>.  This
          may involve working to get the other specifications updated,
          if only to clarify nomenclature.
          </t>

	  <t>Obsolete any previous definition of x-url-encoded. </t>
	    
          <t>Change the <xref target="URL-LS"/> goals to only obsolete
          specifications listed above that are not updated.  Presuming that
          <xref target="RFC3986"/> is updated, explicitly state that 
          conforming URLs are a proper subset of valid URIs, and further state
          that canonical URLs (i.e., the output of the URL parser) not only
          round trip, but also are valid URIs.</t>
	  
          <t>Update and incorporate (or reference) the content currently
          present in <xref target="tantek-slice"/>, probably as an appendix
          to <xref target="URL-LS"/>, so that readers will understand
          what terms are in use and how they map.</t>

          <t>Reconcile how <xref target="appsawg-uri-scheme-reg"/> and
          <xref target="URL-LS"/> handle currently unknown schemes,
          update <xref target="appsawg-uri-scheme-reg"/> to state that
          registration applies to both URIs and URLs, and update
          <xref target="URL-LS"/> to indicate that
          <xref target="appsawg-uri-scheme-reg"/> is how you register
          schemes.</t>

          <t>Have the W3C adopt <xref target="url-workmode"/>.</t>

          <t>Other than keeping on top of <xref target="UTS-46"/> and responding
          to any feedback that may be provided, no changes to any Unicode
          Consortium product is required.</t>
	</list></t>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">

      <t>Helpful comments and improvements to this document have
      come from 
      Anne van Kesteren, 
      Bjoern Hoehrmann,
      Graham Klyne, 
      Julian Reschke,
      and Martin Duerst.
      </t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo currently includes no request to IANA,
        although an updated <xref target="appsawg-uri-scheme-reg"/>
        might add some additional requirements and information to
        <eref target="http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml">IANA
          URI scheme registry</eref> to make clear that the
          schemes serve as URL schemes and IRI schemes as well as
          URI schemes.
      </t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>In addition to the security exposures created when URLs work
      differently in different systems, all of the security considerations
      defined in <xref target="RFC3490"/>, <xref target="RFC3986"/>, 
      <xref target="RFC3987"/>, and <xref target="RFC5895"/> apply to URLs.</t>
    </section>
  </middle>

  <back>
    <references title="Informative References">

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1738.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2396.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3490.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3987.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4395.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5895.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6454.xml"?>

      <reference anchor="appsawg-uri-scheme-reg">
        <front>
          <title>Guidelines and Registration Procedures for New URI Schemes</title>

          <author initials="D.T." surname="Thaler">
            <organization>Microsoft</organization>
          </author>

          <author initials="T.H." surname="Hansen">
            <organization>AT&amp;T Laboratories</organization>
          </author>

          <author initials="T.H." surname="Hardie">
            <organization>Google</organization>
          </author>

          <author initials="L.M." surname="Masinter">
            <organization>Adobe</organization>
          </author>

          <date year="2014" month="October"/>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-appsawg-uri-scheme-reg-04"/>
      </reference>

      <reference anchor="CORS"
                 target="http://www.w3.org/TR/cors/">
        <front>
          <title>Cross-Origin Resource Sharing</title>

          <author initials="A.K." surname="van Kesteren">
          </author>

          <date year="2014" />
        </front>
      </reference>

      <reference anchor="FETCH"
                 target="https://fetch.spec.whatwg.org/">
        <front>
          <title>Fetch Living Standard</title>

          <author initials="A.K." surname="van Kesteren">
          </author>

          <date year="2014" />
        </front>
      </reference>

      <reference anchor="iri-3987bis">
        <front>
          <title>Internationalized Resource Identifiers (IRIs)</title>

          <author initials="M.D." surname="Duerst">
            <organization>Aoyama Gakuin University</organization>
          </author>

          <author initials="M.S." surname="Suignard">
            <organization>Unicode Consortium</organization>
          </author>

          <author initials="L.M." surname="Masinter">
            <organization>Adobe</organization>
          </author>

          <date year="2012" month="October"/>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-iri-3987bis-13"/>
      </reference>

      <reference anchor="iri-comparison">
        <front>
          <title>Comparison, Equivalence and Canonicalization of
          Internationalized Resource Identifiers</title>

          <author initials="L.M." surname="Masinter">
            <organization>Adobe</organization>
          </author>

          <author initials="M.D." surname="Duerst">
            <organization>Aoyama Gakuin University</organization>
          </author>

          <date year="2012" month="October"/>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-iri-comparison-02"/>
      </reference>

      <reference anchor="iri-bidi-guidelines">
        <front>
          <title>Guidelines for Internationalized Resource Identifiers with
          Bi-directional Characters (Bidi IRIs)</title>

          <author initials="M.D." surname="Duerst">
            <organization>Aoyama Gakuin University</organization>
          </author>

          <author initials="L.M." surname="Masinter">
            <organization>Adobe</organization>
          </author>

          <author initials="A.A." surname="Allawi">
            <organization>Diwan Software Limited</organization>
          </author>

          <date year="2012" month="October"/>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-iri-bidi-guidelines-03"/>
      </reference>

      <reference anchor="kerwin-file-scheme">
        <front>
          <title>The file URI Scheme</title>

          <author initials="M.K." surname="Kerwin">
            <organization>QUT</organization>
          </author>

          <date year="2014" month="September"/>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-kerwin-file-scheme-13"/>
      </reference>

      <reference anchor="tantek-slice"
                 target="http://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces">
        <front>
          <title>How many ways can you slice a URL and name the pieces?</title>

          <author initials="T.C." surname="Celik">
            <organization>Mozilla</organization>
          </author>

          <date year="2011" />
        </front>
      </reference>

      <reference anchor="URL-LS"
                 target="https://url.spec.whatwg.org/">
        <front>
          <title>URL Living Standard</title>

          <author initials="A.K." surname="van Kesteren">
          </author>

          <author initials="S.R." surname="Ruby">
          </author>

          <date year="2014" />
        </front>
      </reference>

      <reference anchor="UTS-46"
                 target="http://unicode.org/reports/tr46/">
        <front>
          <title>Unicode IDNA Compatibility Processing</title>

          <author initials="M.D." surname="Davis">
          </author>

          <author initials="M.S." surname="Suignard">
          </author>

          <date year="2014" />
        </front>
      </reference>

      <reference anchor="W3C-URL"
                 target="http://www.w3.org/TR/url/">
        <front>
          <title>URL Working Draft</title>

          <author initials="A.K." surname="van Kesteren">
          </author>

          <author initials="S.R." surname="Ruby">
          </author>

          <date year="2014" />
        </front>
      </reference>

      <reference anchor="whatwg-interop"
                 target="https://url.spec.whatwg.org/interop/test-results/">
        <front>
          <title>URL test results</title>

          <author initials="S.R." surname="Ruby">
            <organization>IBM</organization>
          </author>

          <date year="2014" />
        </front>
      </reference>

      <reference anchor="url-workmode"
                 target="https://github.com/webspecs/url/blob/develop/docs/workmode.md#preface">
        <front>
          <title>URL WorkMode</title>

          <author initials="S.R." surname="Ruby">
            <organization>IBM</organization>
          </author>

          <date year="2014" />
        </front>
      </reference>

      <reference anchor="WP-URL"
                 target="https://specs.webplatform.org/url/webspecs/develop/">
        <front>
          <title>URL Standard</title>

          <author initials="A.K." surname="van Kesteren">
          </author>

          <author initials="S.R." surname="Ruby">
          </author>

          <date year="2014" />
        </front>
      </reference>
    </references>

    <!-- Change Log
v00 2014-12-14 SAR   Initial version
v01 ***TBD***  SAR   fix ID references, fix WG element, fix AREA element,
                     remove unneeded empty elements
    -->
  </back>
</rfc>