wdiff rfc8820xml2.original.xml rfc8820.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> version='1.0' encoding='utf-8'?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->
<!DOCTYPE rfc SYSTEM "../Tools/rfcbootstrap/rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
     docName="draft-nottingham-rfc7320bis-03" number="8820" category="bcp"
     obsoletes="7320" updates="3986"> updates="3986" submissionType="IETF" consensus="true"
     xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true"
     version="3">

  <!-- xml2rfc v2v3 conversion 2.45.0 -->
  <front>
    <title>URI Design and Ownership</title>
    <seriesInfo name="RFC" value="8820"/>
    <seriesInfo name="BCP" value="190"/>
    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization></organization>
      <organization/>
      <address>
        <email>mnot@mnot.net</email>
        <uri>https://www.mnot.net/</uri>
      </address>
    </author>
    <date month="June" year="2020"/>
    <area>art</area>
    <keyword>URI structure</keyword>
    <abstract>
<!-- Quoted text is DNE. -->
      <t>Section 1.1.1 of RFC 3986 defines URI syntax as “a "a federated and
      extensible naming system wherein each scheme’s scheme's specification may further
      restrict the syntax and semantics of identifiers using that
scheme.” scheme."  In
      other words, the structure of a URI is defined by its scheme. While it
      is common for schemes to further delegate their substructure to the URI’s
      URI's owner, publishing independent standards that mandate particular
      forms of substructure in URIs is often problematic.</t>
      <t>This document provides guidance on the specification of URI
      substructure in standards.</t>

    </abstract>

    <note title="Note to Readers">

<t><spanx style="emph">RFC EDITOR: please remove this section and the “URIs” section before the Appendices before publication</spanx></t>
      <t>This is a proposed revision of RFC7320, aka BCP190. The -00 draft is a copy of the published RFC;
subsequent revisions will update it.</t>

<t>The issues list for this draft can be found at <eref target="https://github.com/mnot/I-D/labels/rfc7320bis">https://github.com/mnot/I-D/labels/rfc7320bis</eref>.</t>

<t>The most recent (often, unpublished) draft is at <eref target="https://mnot.github.io/I-D/rfc7320bis/">https://mnot.github.io/I-D/rfc7320bis/</eref>.</t>

<t>Recent changes are listed at <eref target="https://github.com/mnot/I-D/commits/gh-pages/rfc7320bis">https://github.com/mnot/I-D/commits/gh-pages/rfc7320bis</eref>.</t>

<t>See also the draft’s current status in the IETF datatracker, at
<eref target="https://datatracker.ietf.org/doc/draft-nottingham-rfc7320bis/">https://datatracker.ietf.org/doc/draft-nottingham-rfc7320bis/</eref>.</t>

    </note> document obsoletes RFC 7320 and updates RFC 3986.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>URIs <xref target="RFC3986"/> target="RFC3986" format="default"/> very often include
      structured application data. This might include artifacts from
      filesystems (often occurring in the path component) and user information
      (often in the query component). In some cases, there can even be
      application-specific data in the authority component (e.g., some
      applications are spread across several hostnames to enable a form of
      partitioning or dispatch).</t>

      <t>Implementations can impose further constraints upon the structure of
      URIs; for example, many Web web servers use the filename extension of the
      last path segment to determine the media type of the response. Likewise,
      prepackaged applications often have highly structured URIs that can only
      be changed in limited ways (often, just the hostname and port on which
      they are deployed).</t>
      <t>Because the owner of the URI (as defined in <xref target="webarch"/> target="webarch" format="default"/>, Section 2.2.2.1) is choosing to use the
server or the application, this can be seen as reasonable delegation of authority. However, when
such conventions are mandated by a party other than the owner, it can have several potentially
detrimental effects:</t>

<t><list style="symbols">
  <t>Collisions
      <ul spacing="normal">
        <li>Collisions - As more ad hoc conventions for URI structure become standardized, it becomes more
likely that there will be collisions between them (especially considering that servers,
applications, and individual deployments will have their own conventions).</t>
  <t>Dilution conventions).</li>
        <li>Dilution - When the information added to a URI is ephemeral, this dilutes its utility by reducing
its stability (see <xref target="webarch"/> target="webarch" format="default"/>, Section 3.5.1), 3.5.1) and can cause several alternate forms of the URI
to exist (see <xref target="webarch"/> target="webarch" format="default"/>, Section 2.3.1).</t>
  <t>Rigidity 2.3.1).</li>
        <li>Rigidity - Fixed URI syntax often interferes with desired deployment patterns. For example, if an
authority wishes to offer several applications on a single hostname, it becomes difficult to
impossible to do if their URIs do not allow the required flexibility.</t>
  <t>Operational flexibility.</li>
        <li>Operational Difficulty - Supporting some URI conventions can be difficult in some
implementations. For example, specifying that a particular query parameter be used with “HTTP” "http"
URIs can preclude the use of Web web servers that serve the response from a filesystem. Likewise, an
application that fixes a base path for its operation (e.g., “/v1”) "/v1") makes it impossible to deploy
other applications with the same prefix on the same host.</t>
  <t>Client host.</li>
        <li>Client Assumptions - When conventions are standardized, some clients will inevitably assume that
the standards are in use when those conventions are seen. This can lead to interoperability
problems; for example, if a specification documents that the “sig” "sig" URI query parameter indicates
that its payload is a cryptographic signature for the URI, it can lead to undesirable behavior.</t>
</list></t> behavior.</li>
      </ul>
      <t>Publishing a standard that constrains an existing URI structure in ways that aren’t aren't explicitly
allowed by <xref target="RFC3986"/> target="RFC3986" format="default"/> (usually, by updating the URI scheme definition) is therefore sometimes
problematic, both for these reasons, reasons and because the structure of a URI needs to be firmly under
the control of its owner.</t>
      <t>This document explains some best current practices for establishing URI structures, conventions, and
formats in standards. It also offers strategies for specifications in <xref target="alternatives"/>.</t> target="alternatives" format="default"/>.</t>
      <section anchor="intended-audience" title="Intended Audience"> numbered="true" toc="default">
        <name>Intended Audience</name>
        <t>This document’s document's guidelines and requirements target the authors of specifications that constrain the
syntax or structure of URIs or parts of them. Two classes of such specifications are called out
specifically:</t>

<t><list style="symbols">
  <t>Protocol
        <ul spacing="normal">
          <li>Protocol Extensions (“Extensions”) ("Extensions") - specifications that offer new capabilities that could apply
to any identifier, identifier or to a large subset of possible identifiers; identifiers, e.g., a new signature mechanism
for ‘http’ "http" URIs, metadata for any URI, or a new format.</t>
  <t>Applications format.</li>
          <li>Applications Using URIs (“Applications”) ("Applications") - specifications that
          use URIs to meet specific needs; needs,
e.g., an HTTP interface to particular information on a host.</t>
</list></t> host.</li>
        </ul>
        <t>Requirements that target the generic class “Specifications” "Specifications" apply to all specifications, including
both those enumerated above and others.</t>
        <t>Note that this specification ought not be interpreted as preventing the allocation of control of
URIs by parties that legitimately own them, them or have delegated that ownership; for example, a
specification might legitimately define the semantics of a URI on IANA’s Web IANA's web site as part of
the establishment of a registry.</t>
        <t>There may be existing IETF specifications that already deviate from the guidance in this document.
In these cases, it is up to the relevant communities (i.e., those of the URI
scheme as well as any relevant community that
which
produced the specification in question) to determine an appropriate outcome; outcome, e.g., updating
the scheme definition, definition or changing the specification.</t>
      </section>
      <section anchor="notational-conventions" title="Notational Conventions"> numbered="true" toc="default">
        <name>Notational Conventions</name>
       <t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
“RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and “OPTIONAL” "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP&nbsp;14
       <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="best-current-practices-for-standardizing-structured-uris" title="Best numbered="true" toc="default">
      <name>Best Current Practices for Standardizing Structured URIs"> URIs</name>
      <t>This section updates <xref target="RFC3986"/> target="RFC3986" format="default"/> by advising Specifications how they should define structure and
semantics within URIs. Best practices differ differ, depending on the URI component in question, as
described below.</t>
      <section anchor="uri-schemes" title="URI Schemes"> numbered="true" toc="default">
        <name>URI Schemes</name>
        <t>Applications and Extensions can require the use of one or more specific URI scheme(s); schemes; for example, it is perfectly
acceptable to require that an Application support ‘http’ "http" and ‘https’ "https" URIs. However, Applications
ought not preclude the use of other URI schemes in the future, unless they are clearly only usable
with the nominated schemes.</t>
        <t>A Specification that defines substructure for URI schemes overall (e.g., a prefix or suffix for URI
scheme names) MUST <bcp14>MUST</bcp14> do so by modifying <xref target="BCP35"/> target="BCP35" format="default"/> (an exceptional circumstance).</t>
      </section>
      <section anchor="uri-authorities" title="URI Authorities"> numbered="true" toc="default">
        <name>URI Authorities</name>
        <t>Scheme definitions define the presence, format format, and semantics of an
        authority component in URIs; all other Specifications MUST NOT constrain, <bcp14>MUST
        NOT</bcp14> constrain or define the structure or the semantics for URI
        authorities, unless they update the scheme registration itself, itself or the
        structures it relies upon (e.g., DNS name syntax, as defined in Section 3.5 of <xref target="RFC1034"/>).</t>
        target="RFC1034" sectionFormat="of" section="3.5"/>).

</t>
        <t>For example, an Extension or Application cannot say that the “foo” "foo" prefix in
“http://foo_app.example.com”
"https://foo_app.example.com" is meaningful or triggers special handling in
URIs, unless they update either the HTTP "http" URI scheme, scheme or the DNS hostname
syntax.</t>
        <t>Applications can nominate or constrain the port they use, when applicable. For example,
BarApp could run over port nnnn (provided that it is properly registered).</t>
      </section>
      <section anchor="uri-paths" title="URI Paths"> numbered="true" toc="default">
        <name>URI Paths</name>
        <t>Scheme definitions define the presence, format, and semantics of a path component in URIs, although these are often delegated to the application(s) Application(s) in a given deployment.</t>
        <t>To avoid collisions, rigidity, and erroneous client assumptions, Specifications MUST NOT <bcp14>MUST NOT</bcp14> define a
fixed prefix for their URI paths; paths -- for example, “/myapp”, "/myapp" -- unless allowed by the scheme definition.</t>
        <t>One such exception to this requirement is registered “well-known” "well-known" URIs, as specified by
<xref target="RFC8615"/>. target="RFC8615" format="default"/>. See that document for a description of the applicability of that mechanism.</t>
        <t>Note that this does not apply to Applications defining a structure
        of URIs paths “under” a URI's path "under" a resource
controlled by the server. Because the prefix is under control of the party deploying the
application,
Application, collisions and rigidity are avoided, and the risk of erroneous client assumptions is
reduced.</t>
        <t>For example, an Application might define “app_root” "app_root" as a deployment-controlled URI prefix.
Application-defined resources might then be assumed to be present at “{app_root}/foo” "{app_root}/foo" and
“{app_root}/bar”.</t>
"{app_root}/bar".</t>
        <t>Extensions MUST NOT <bcp14>MUST NOT</bcp14> define a structure within individual URI components (e.g., a prefix or suffix),
again to avoid collisions and erroneous client assumptions.</t>
      </section>
      <section anchor="uri-queries" title="URI Queries"> numbered="true" toc="default">
        <name>URI Queries</name>
        <t>The presence, format format, and semantics of the query component of URIs is are dependent upon many factors, factors
and can be constrained by a scheme definition. Often, they are determined by the implementation of
a resource itself.</t>
        <t>Applications can specify the syntax of queries for the resources under their control. However,
doing so can cause operational difficulties for deployments that do not support a particular form
of a query. For example, a site may wish to support an Application using “static” "static" files that do not
support query parameters.</t>
        <t>Extensions MUST NOT <bcp14>MUST NOT</bcp14> constrain the format or semantics of queries, to avoid collisions and erroneous
client assumptions. For example, an Extension that indicates that all query parameters with the
name “sig” "sig" indicate a cryptographic signature would collide with potentially preexisting query
parameters on sites and lead clients to assume that any matching query parameter is a signature.</t>

<t>HTML
        <t>Per the "Form submission" section of <xref target="W3C.REC-html401-19991224"/> target="HTML5"/>, HTML constrains the syntax of
	query strings used in form submission.
New form languages are encouraged to allow creation of a broader variety of URIs
(e.g., by allowing the form to create new path components, and so forth).</t>
      </section>
      <section anchor="uri-fragment-identifiers" title="URI numbered="true" toc="default">
        <name>URI Fragment Identifiers">

<t>Section 3.5 of <xref target="RFC3986"/> Identifiers</name>
        <t><xref target="RFC3986" sectionFormat="of" section="3.5"/> specifies fragment identifiers’ identifiers' syntax and semantics as being dependent
upon the media type of a potentially retrieved resource. As a result, other Specifications MUST NOT <bcp14>MUST NOT</bcp14>
define structure within the fragment identifier, unless they are explicitly defining one for reuse
by media types in their definitions (for example, as JSON Pointer <xref target="RFC6901"/> target="RFC6901" format="default"/> does).</t>
        <t>An Application that defines common fragment identifiers across media types not
controlled by it would engender interoperability problems with handlers for those media types
(because the new, non-standard syntax is not expected).</t>
      </section>
    </section>
    <section anchor="alternatives" title="Alternatives numbered="true" toc="default">
      <name>Alternatives to Specifying Structure in URIs"> URIs</name>
      <t>Given the issues described in <xref target="intro"/>, target="intro" format="default"/>, the most successful strategy for Applications and
Extensions that wish to use URIs is to use them in the fashion for which they were designed: as links that
are exchanged as part of the protocol, rather than statically specified syntax. Several existing
specifications can aid in this.</t>
      <t><xref target="RFC8288"/> target="RFC8288" format="default"/> specifies relation types for Web web links. By providing a framework for linking on the
Web, where every link has a relation type, context context, and target, it allows Applications to define a
link’s
link's semantics and connectivity.</t>
      <t><xref target="RFC6570"/> target="RFC6570" format="default"/> provides a standard syntax for URI Templates that can be used to dynamically insert
Application-specific variables into a URI to enable such Applications while avoiding impinging upon
URI owners’ owners' control of them.</t>
      <t><xref target="RFC8615"/> target="RFC8615" format="default"/> allows specific paths to be ‘reserved’ "reserved" for standard use on URI schemes that opt into
that mechanism (‘http’ ("http" and ‘https’ "https" by default). Note, however, that this is not a general “escape
valve” "escape
valve" for applications Applications that need structured URIs; see that specification for more information.</t>
      <t>Specifying more elaborate structures in an attempt to avoid collisions is not an acceptable
solution,
solution and does not address the issues described in <xref target="intro"/>. target="intro" format="default"/>. For example, prefixing query parameters
with “myapp_” "myapp_" does not help, because the prefix itself is subject to the risk of collision (since
it is not “reserved”).</t> "reserved").</t>
    </section>
    <section anchor="security-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document does not introduce new protocol artifacts with security considerations. It prohibits
some practices that might lead to vulnerabilities; for example, if a security-sensitive mechanism
is introduced by assuming that a URI path component or query string has a particular meaning, false
positives might be encountered (due to sites that already use the chosen string). See also
<xref target="RFC6943"/>.</t> target="RFC6943" format="default"/>.</t>
    </section>
    <section anchor="iana-considerations" title="IANA Considerations">

<t>There are numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no direct IANA actions specified in this document.</t> actions.</t>
    </section>
  </middle>
  <back>

    <references title='Normative References'>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="webarch" target="http://www.w3.org/TR/2004/REC-webarch-20041215"> target="https://www.w3.org/TR/2004/REC-webarch-20041215">
          <front>
            <title>Architecture of the World Wide Web, Volume One</title>
            <author initials="I." surname="Jacobs" fullname="Ian Jacobs">
      <organization></organization>
              <organization/>
            </author>
            <author initials="N." surname="Walsh" fullname="Norman Walsh">
      <organization></organization>
              <organization/>
            </author>
            <date year="2004" month="December" day="15"/> month="December"/>
          </front>
        </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
        <name>Informative References</name>

        <reference  anchor="RFC3986" target='https://www.rfc-editor.org/info/rfc3986'> anchor="BCP35" target="https://www.rfc-editor.org/info/bcp35">
          <front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <title>Guidelines and Registration Procedures for New URI Schemes</title>
            <author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author> initials="D." surname="Thaler" fullname="Dave Thaler" role="editor">
             <organization/>
            </author>
            <author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author> initials="T." surname="Hansen" fullname="Tony Hansen">
             <organization/>
            </author>
            <author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author> initials="T." surname="Hardie" fullname="Ted Hardie">
             <organization/>
            </author>
            <date year='2005' month='January' />
<abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.  [STANDARDS-TRACK]</t></abstract> year="2015" month="June"/>
          </front>
          <seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/> name="BCP" value="35"/>
          <seriesInfo name='DOI' value='10.17487/RFC3986'/> name="RFC" value="7595"/>
        </reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8615.xml"/>

      <reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> anchor="HTML5" target="https://html.spec.whatwg.org/#form-submission">
          <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
            <title>HTML - Living Standard</title>
           <author>
            <organization>WHATWG</organization>
           </author>
            <date year='1997' month='March' month="June" year="2020" />
<abstract><t>In many standards track documents several words are used to signify
          </front>
         <refcontent>Section 4.10.21</refcontent>
        </reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6901.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8288.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6570.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6943.xml"/>
      </references>
    </references>
    <section anchor="changes-from-rfc7320" numbered="true" toc="default">
      <name>Changes from RFC 7320</name>
      <t>Many of the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>

<reference  anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>

    </references>

    <references title='Informative References'>

<reference anchor="BCP35" target="https://tools.ietf.org/html/bcp35">
  <front>
    <title>Guidelines and Registration Procedures for New URI Schemes</title>
    <author initials="D." surname="Thaler" fullname="Dave Thaler">
      <organization>Microsoft</organization>
    </author>
    <author initials="T." surname="Hansen" fullname="Tony Hansen">
      <organization>AT&amp;T Laboratories</organization>
    </author>
    <author initials="T." surname="Hardie" fullname="Ted Hardie">
      <organization>Google</organization>
    </author>
    <date year="2015" month="June"/>
  </front>
  <seriesInfo name="BCP" value="35"/>
  <seriesInfo name="RFC" value="7595"/>
</reference>

<reference  anchor="RFC1034" target='https://www.rfc-editor.org/info/rfc1034'>
<front>
<title>Domain names - concepts and facilities</title>
<author initials='P.V.' surname='Mockapetris' fullname='P.V. Mockapetris'><organization /></author>
<date year='1987' month='November' />
<abstract><t>This RFC is the revised basic definition of The Domain Name System.  It obsoletes RFC-882.  This memo describes the domain style names and their used for host address look up and electronic mail forwarding.  It discusses the clients and servers in the domain name system and the protocol used between them.</t></abstract>
</front>
<seriesInfo name='STD' value='13'/>
<seriesInfo name='RFC' value='1034'/>
<seriesInfo name='DOI' value='10.17487/RFC1034'/>
</reference>

<reference  anchor="RFC8615" target='https://www.rfc-editor.org/info/rfc8615'>
<front>
<title>Well-Known Uniform Resource Identifiers (URIs)</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<date year='2019' month='May' />
<abstract><t>This memo defines a path prefix for &quot;well-known locations&quot;, &quot;/.well-known/&quot;, in selected Uniform Resource Identifier (URI) schemes.</t><t>In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space.  It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.</t></abstract>
</front>
<seriesInfo name='RFC' value='8615'/>
<seriesInfo name='DOI' value='10.17487/RFC8615'/>
</reference>

<reference anchor="W3C.REC-html401-19991224"
           target='http://www.w3.org/TR/1999/REC-html401-19991224'>
<front>
<title>HTML 4.01 Specification</title>

<author initials='D.' surname='Raggett' fullname='Dave Raggett'>
    <organization />
</author>

<author initials='A.' surname='Hors' fullname='Arnaud Le Hors'>
    <organization />
</author>

<author initials='I.' surname='Jacobs' fullname='Ian Jacobs'>
    <organization />
</author>

<date month='December' day='24' year='1999' />
</front>

<seriesInfo name='World Wide Web Consortium Recommendation' value='REC-html401-19991224' />
<format type='HTML' target='http://www.w3.org/TR/1999/REC-html401-19991224' />
</reference>

<reference  anchor="RFC6901" target='https://www.rfc-editor.org/info/rfc6901'>
<front>
<title>JavaScript Object Notation (JSON) Pointer</title>
<author initials='P.' surname='Bryan' fullname='P. Bryan' role='editor'><organization /></author>
<author initials='K.' surname='Zyp' fullname='K. Zyp'><organization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham' role='editor'><organization /></author>
<date year='2013' month='April' />
<abstract><t>JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document.</t></abstract>
</front>
<seriesInfo name='RFC' value='6901'/>
<seriesInfo name='DOI' value='10.17487/RFC6901'/>
</reference>

<reference  anchor="RFC8288" target='https://www.rfc-editor.org/info/rfc8288'>
<front>
<title>Web Linking</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<date year='2017' month='October' />
<abstract><t>This specification defines a model for the relationships between resources on the Web (&quot;links&quot;) and the type of those relationships (&quot;link relation types&quot;).</t><t>It also defines the serialisation of such links in HTTP headers with the Link header field.</t></abstract>
</front>
<seriesInfo name='RFC' value='8288'/>
<seriesInfo name='DOI' value='10.17487/RFC8288'/>
</reference>

<reference  anchor="RFC6570" target='https://www.rfc-editor.org/info/rfc6570'>
<front>
<title>URI Template</title>
<author initials='J.' surname='Gregorio' fullname='J. Gregorio'><organization /></author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='M.' surname='Hadley' fullname='M. Hadley'><organization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<author initials='D.' surname='Orchard' fullname='D. Orchard'><organization /></author>
<date year='2012' month='March' />
<abstract><t>A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet.   [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6570'/>
<seriesInfo name='DOI' value='10.17487/RFC6570'/>
</reference>

<reference  anchor="RFC6943" target='https://www.rfc-editor.org/info/rfc6943'>
<front>
<title>Issues in Identifier Comparison for Security Purposes</title>
<author initials='D.' surname='Thaler' fullname='D. Thaler' role='editor'><organization /></author>
<date year='2013' month='May' />
<abstract><t>Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources.  In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security principal may access the resource, what level of authentication or encryption is required, etc.  If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result.  This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols.</t></abstract>
</front>
<seriesInfo name='RFC' value='6943'/>
<seriesInfo name='DOI' value='10.17487/RFC6943'/>
</reference>

    </references>

<section anchor="changes-from-rfc7320" title="Changes from RFC7320">

<t>Many of the requirements of RFC7320 were removed, of RFC 7320 were removed, in the spirit of making this BCP guidance, guidance rather than rules.</t>
    </section>
    <section anchor="acknowledgments" title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>Thanks to David Booth, Dave Crocker, Tim Bray, Anne <contact fullname="David Booth"/>, <contact fullname="Dave
      Crocker"/>, <contact fullname="Tim Bray"/>, <contact fullname="Anne van Kesteren, Martin Thomson, Erik Wilde,
Dave Thaler
      Kesteren"/>, <contact fullname="Martin Thomson"/>, <contact
      fullname="Erik Wilde"/>, <contact fullname="Dave Thaler"/>, and Barry Leiba <contact
      fullname="Barry Leiba"/> for their suggestions and feedback.</t>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAECCEl4AA5VbbXPbRpL+jl8xR1ed5RRJvdhOYvnq7mTZSbRrS15JudTV
1VVqCAzJWYEYLAYQzVX5v9/T3TPAgJKTumQrKxHETE+/PP1092g2m2WtbUtz
qn69vlDvjberSumqUFfbyjR+beuscHmlN/hG0ehlO6tc29pqtdabWbPMf3h5
crSwfnb0Mit0iy+dHJ0cZTl+XLlmd6oWeZ11NT3yp+rlmx+/z9zCu9Lw7/Ry
ltm6OVVt0/n25OjozdFJphujT5Vu2mzrmrtV47r6NLszO/xWiJweX8/brjFZ
5ltI+7suXYXNd8ZntT1V/9O6fKrwH1sVpmqnyrumbczS46fdJvzQNjbHo9xt
ah1+2ODLeGSr0lbmf7NMd+3aNaeZmmUK/9gKQn+aq8teBfyxaOeTbu72n7hm
pSv7T91aV53yJ2ajbXmqNtDif9J/5pVp+UHXQO5129b+9PBwu93O49PDLKtc
s8Ea94bW2JqFbvK1LNfqZmVaeTG8t305x7aHt9eHUOerw+sP57Pwyow+OD45
fi2vitnP8MC2hrWp3FK1a6N+c01ZqN9sgR/NYqr+y5XdxqiryvCbvVboH9FM
r52LufqLzmHj/mPRzoWu9h9AyqfXuJyr33Tp13tLXJIWqr1H/SLR+45ezY5P
ZjhjZqtlqrd3559fvn6sNVJ361zp59a0S1bdut2Uh3DclyNF/dxBH+QXnuPj
2qwsXIhNqz43LjcFNOgV9lSXZstuepOvzcb4P1Xa+7m6XevSNHsnfq/vzf4T
OrD6ZPPGebdsn1zudq5+0ZU31d5yt67a7T/h5c5u//VWfdQLh+O4xgaJn1y2
KazZX9YU+w941Z+dW5VmZJzj17Oj7/kTb2gfMlFQCdkHCPE6/Hb90znw4fUb
2DGbzWZKL0jZeZtlN/BV0vnxHP+Sx+KrjCyqMEs2DyPErmr1F6W9mmi1NIXB
0SAnWc58aU3l7aI0dABEK77sW7NR27VpjK0yo/O18my751752uR2aXOx9Ebv
1LJrECWNgrkZQzhm4obYwCPIq9bmnqSzBEB4H2CqOk+7tWvdZrL8fKIuKuV4
NUI3YA+vFeGNFtB8HuvD8Qq12Cnb+iAgQmVtcRLb0lcIwiAkfDBs4AGCvbxw
X7OCGmgP2yjfLYaN8DXaGVvhyI6wf6rqblFapADITDhaGwZTxYgLe/uMTgKN
VGReVQOwbd6VuqH9N3z40Ra2ouU9yQnPNZWqGwcjUITm8yy7XdMZXd4RCNOz
e6jOqxXCTlc5VFGJbkbmwB5s7b19ehHnwX2Apeb3S/pP636/Nhr+4LPsO3Kd
D+8vbq+uT1VdGu0NjLpx96QiSOODq5FRae8JyT/pP14YHJS1qc5q0o7NIXD4
lJUnUn4XDof/aTpY7TzM2Jh768MZIAflwqnSd5oC4fjNEUGCUbOjI0m78nLu
6l0E6WAdrIS332akAvOPjnQXV/Zqa8tSSfqFh7CS8YP3HeTEyy2jFR9VNsk1
nQqfdjgxbPtvESFXtl13izn865Dy0uHF7P1hqRem9IcDCfj3sMHGeRIiJ1kO
2NRT1VW9vC+SEyVbcL4L+1jHOwxLH9La17JkvtbVilAYWqZDmD8XleICMXO4
Ws9qjXf3hL4xRiGrSAiwcAiCvGua4O5t58mr6OnFh9ufCM40odEdRQmCud87
eTCkE/j04R9QJz4aO+nGFgUAM3sGUGgbV3TiZg/PLP36Ncs4fB4e/gUGJ8D7
+lXdm2YXoslWedkVCXhALXUdfZBlJp+C1jd2tW7771PYLoGsPls2bqOWQBPB
Qx+Mp1xOuhAYENfT7Zp5E0hX1b7g+OiA6KpPudjwIIrFr8Azm102vDMn4PMO
rCJH1AnuNYYd0Nwb9sJE+lmMej5GXFNSqm13gyzZgZmv5lNZOVlAvMXXYJZQ
CyVPim5oT5dqDXelTMZYaSpNiUEzhlGoMazREnR+4GphPY6fr1/AahcbgAbB
VdiDpLcbCu8ec3N8Do+ABQH/dcSwFN/JqG85EM0XTQtOCVJ3xLwy6PReEofA
DBmHRI05TNCDnpQaMcd28WbFCIrDFKDZDTKcvLwxhdWq3dWR52VIYBDJI4l8
tHdmaz32hopAh+8QJcVYgWLONVGSNRyo3KWexp7J6YB04Co8XZhMIrUge5UW
AYgft3rne1D4Ozg/ixZNwJ5Ug6sT2m/XFnkYj3dsPCSg0u0AH1D8O5PrqBNO
VlENlAwO9JArsfPDQ6C/CJfIHU7m9O/xC86Za+ckL7uo56B3xeA48qOpoGXA
SW+gEewGr/JOHCfk2GCZ3kNBndyW/G1KLKMCWucUQdU9kYPoniGTcobX7Hi7
wA2g2Wo47JSyPYnAxohuXCO7YTFdlrsMhm8sO2apzHKJU/tTpDt17soypIaZ
OgMSUKZCRKxdPpKGvHFUZ+G0OYVUTKz2n6ZgMeRzWQnUrYQfwfbsCRLRnIKg
q3zYemHaLWkOX9ioA8OxTWJzsCDpN5ElqeD/U6yc+uKU/QScxIIjdDij+AZX
b7Iha0ZoDlSWno3c5zv13pYdG2kG/iSijMBLFwXsAI/o2ZepiU9B0cEFCloB
BycqhqVKgiHYDcHQoepcQWImaa1eyLMDOMuTvvhy/hqeKEcio4pnR6vqEiFc
Uf7uSVXwc+xAePWF0vg3Fz+Zv8TifORru7IFSTJTP9kvErORtUaoxl5LQ1XM
FkkUWvWWgnvQLiEMyePn6qcUsCxcnWqKAZG3lOoZUR38rxnOM4IUKFpR7JUD
BIy8qrDLJXFKQjPSKGGrMHdCN0f7ipEZf/ABMixUVrota6kBIeITLEvoSQzB
uriqjVRukOh93IM0c9PVBD9cFJC/k47SwAiBP8hlJYuJcGky2NOQJLBd79k6
5cucHOkDnB/qpR06oohshckvt7efJ9iAz0gCAKIlddMZyVngFMgWMVqS0Ala
EJRXnN91kuFT3Bf7JYSBV1nCU4h4Logac3ohaCDPdlGFKqTcyeH98eQFQOyO
o2LfWOxD2EIAbeQGfEzOi5QCcDrs2tN9+oh8g+12XlrywjMw2E3dBhzjAN7H
0jFQCdHglwNAIDvcWwQnUEfTakbKMhXycygfeCmYmJS8FZyg5P5oM6BZ4FZk
n5JIBs7M8cR6EtfD6qHk2U/4FD97lU2shHwPpmri7WrCLrnvMASF1HPzfAB8
nSxU613pIIlUDs2ubt2q0TWyqqIun2ZcX4Ych1X7tBLlRxFACMB5bWEAqdY1
MMPnoSzUvapC8o9sh3okgk30tXEqgT6ZBUgcgGM/b/FV8gfbIndx+EoSHFHd
g853lCWm9IRrGgkmCVIpdyXvM13j3M4piMsx8oDWUjMmqTqxlAsujW9y8UeJ
POSXRUIynqjIK2MKBjgqmGyzgSeRwpqMvg9FgLKX3ABoQ0H9qMalQ7Ou2D0X
BkAei46aeh1cTrKfUBqJOh8p009TZ2S5M8liflwHq4tWShyGY0pM1BBZ2bDD
yPe80KaYeuy98V+/UpHyjCsTagMU6qwrEE652TvUc6nYk0ZZAOHgy9x5S9i7
tAnGu49dSQhZyFPNY+5MHxKWxtwIVLvdOkQ74tqELgT1c8Z7aC42yhIncV2b
9U/hYMyUPjeudeAs6kNk2qCtk+EXIN3sSbkl3VVmi+VrCXxScjhTVwqr3kn2
Jp4/NIimTDiJc5SkJu5qmJaLkIikSTfprRLc1bzZENEbQ7TbeupAk2mfU3H6
nFWFysK0mksoekK7c9zTz7yKuA5D7VmK0L/64HmkhPTJN9VAgSNFgcOmOEVf
wXHcvIVwQfxKUYIL5EPnnC2S3JiyMuYLIRlcj9yKIXLwrZVBvGEvdgI1uRkJ
OBELsKaRCcbST0NdTBSOwUEQ31TdJrYQF9QfIs/mVEYtJmosRZi2+x1D11G1
TcRkYeSUyHC8kKdcx7EbgIygb2hsDRgihf9iJ3qJ3oRCA74F1RDjJpZLzs/G
ZPYbu30Bml2c5+ylHp3tNTi5OTBaW4opwcG0tSk4iHcuzi7PEPjMQVDl8ck0
FXFLBsMevhj1+MVGuuc76Rhx7UMV45AyuM/ylGPpkmp4EureMi0mUsM2j41C
howEkubZRRXwPfQapFna1bHr2UBV95paS26z6SqJ2AM7N/NpsH9SXoZMgzNu
DdxHi1yZVKs1t21M8USrEmIhbXvJTaPiHCEAjwRTaPhEwCNivzG+Y6pjVT5K
c2xvrrOjE412DagNB41093xIF9Ktu0N9zb1nNfn0683tZCr/ry6v+OfrD3/7
9eL6w3v6+eaXs48f+x/iN25+ufr14/vhJ/k8w5vnV58+fbh8Ly/jU7X30aez
/55Irp1cfb69uLo8+zh5ZD6Gakmz4+hBlevzxi6kzH93/lkdvwqU4eT4+A0o
g/zy4/EPr/AL8TfZjNsT8qt0F+raMNIwHgC2QQxLSqY+82sKLPJQ0mT2TL2j
LH0esvTnUZa+6SknmeJm3BwJaTK2jsNIFBIOBIeq/oI6t/T22PPXUtDsFOSh
FBIicsiFlPeH2CRCHbrtc5F44BNUuvAsgBvW1NOqetfu22ips07Hql4Y0LM5
e1U64spG+YK0nCROIpWBBsR6pU8HQ0gd+Bf7tJjjtKaiNGdqmOembnUoKeKK
AgtVmrGQOrmOi8mP5OEf/fOglb4dk8qdDVj9VI0lpcsgcN8UXnZkBGpyo7Ly
Q8sqB5NuCJzJ4TpPgmd9sVM5BD/jc1gNSj0bG16OFsdaoyFH36EJkjgur8tY
jOm+jKI5z5J+Cm+EwRDP7vwLxaGOwhnMEP63cUUoUh8eeF5KvJuZPCleACS3
DQKTmGVuXgR8IUnOQu1P48PsZh+nfJpFIJsn7jgNhOPx1Iwg8XF3N46Q3lKg
ZmKOvUiJ0DXwR0bINIUNBLLZy2lRRXo4ytioYZSSIHGTjoFB9U25nPYL9yyd
PBlJhtIKNYFjl/r95Q3bIbRhpmnbMmkPkUIeHv4DSHF89BJQRlofNRegrQ9D
Q7gZRQJij/zZ66ErpyZL5ybRQ2yVTcL1AXz8O8BwHhamGcqEInBjNLW/l13J
R2vsasU1hDTuQDeqogzjAaGZT+jM2NDJNML3Buft9UXq6DvBopL5HrAQksTA
4cyXVgnSOZZNqaXBFXvoNCD0xh2Z7J1usHTg5E1XcQjJEhX+UQdhBFnEipqx
iOv5chfsjrzA/eg+CD7rdv3/dv/pE/6/N2MZVIuqbE0wFRiN5kKIuncJ33P7
bWtAK6c3tbL3/NXY0CP+BRp872yRdGinqgnNQhHNNA2kcJ0PPRRpmdSBMH8r
AsOJdbbkdmNwt1BsS8+OT7nfDJkcbnaQfdK7UdIReJID4RBXlA2pzOuRSrRg
fVp/Kv41Gk5NiMDN7iqk+EnUbs/eeb9Mwu7H74+BhHNFc0KB5MhNuIxSkh3r
SNwT5YfmL39Is/JYmz0uGgoHcOD2ZSxORo4vpw0tl/0KmLWoJtx+mDC79q5r
UJuHEqJMlMc9QmIFQ3MjAoGXBkbavJBpHw0ixGcCycxGI5Gktc8Ff2w0k2+y
a1ELLs7QG+vvaOU/8imIknEj3RRPQF2KblKtBE+bQKrfG+faCdlRJ24+SxTB
bscnnqfYMovYG5UX56TtOowjuU1YBCoqMdzS5HnyEPf9esjASmQs/XChmwnO
kRCiRzGSGDWQt2S6MaJm/tsp/sU00yvGwsch/adxnGTyv3V8OUfKgz/P1f14
N4Gr6Jl8bSVeHOH5J882ad7saK4Thx48IApQHgdgj+NcXcncMJkJhhqq9+9x
F54q0CEcQn5+KqeE9rxKbvLgCP8QRfRN0sE1JFAEx4JvDZwyK5wMEJJ5jksm
Dv30IK6djq8CvjAURBar9y/XZJwiWOl7cwYtFTiV0zSCIVfoVxmHjlxGmtD1
BptPZCqQ7p7F9/aazf4brjxOxcFZyDdTXwkanf65i2ZPuKj6NuuRHB3b4LFV
UD4Svh82ZMwypKUe3/uDPvmWaQILW0iMpgNXipK+dSFXHZItqR6xbWiHcnM9
jiJIC8P0gRtyG7pc0C+T9vg9GzcIBCP8cvvpI/HC316ez+mWJ11bfHV0PDt+
8+bN8ckJ1bxJP/6xZ/MAHzt5GTbZSu48oMzYWO85r16GnqAqdbXqdLx1AzxA
HPAVAWmioTzNGzOMvdWicXTHSt1rmFsSIFfBAbsovumt2LPgPbAUL2K4FTnm
P6Elj5DCV9v1iHP9BEk4GV8MzdHhmmDPn4dCO2Z4BF98NemrPn/6Kp+muTXJ
2+NZ1t/nGN+s0CPPaGgUD1gYEsucJu+MSoCAqfrDMiZ7VOmH9MBaeyz94xp0
mKwMHAIqZdxpDCyfUd3XHyDWtLYZsdeDcc/Qq7/cXF2qz447MqE4+f7N0TG0
S0SG7HM2hptRKRvvKT6h/ng7JxWJ0GhMZcDGJSJNtTKMxfvDtn7UJsHKNQot
L1hOPb1kh+wgHfbA/abYs5r1w63gEVYYGlQK5wrM/5k6S+Yk5MQ3w6j35tHl
x4dno7FKlv3MjLwd7uWNuloPD3L366tcDOWbdeC5SEGeqrEwxdnxqfY7MClK
s/ZjQuh789Ynl142fTdD+7VYjDqDhtMs4Y4pTsnyqPTuQs9T/Cve8hm6voFV
ygQFxYQeLrFIuuHIGIh2qPXAr+WSQITSbK8BTOlU2yK2CKH+wM9PfvxxFNeo
tYPXsf+Qdqg5zaKD++7C9VLh00tCWPpLA/4efWdoi2V8/50vBtO9NGAmPYc3
SQQnu/AgrjVfhCDJLII7WAx0fmwdbv+G6ogWpGvGA9IQJ3JVRQB2LzcWQoC9
/uEIx+yvxibT1+CgsSt0axCoQyIMDIthnrbe0b1nMQJSg2naERHuW3ME3lQ4
Eyb0V2GGO3Jcb42OteWryJzXuR2wqa30pbnpwcMCnkI83ysxNoMludKKOusl
kQJHmPdzIqQoYornMrmMKmCWVY2aYjL4qFuWPxtXYOrgid7ggkFSA5df8F95
wKrr2CgcSrUAA1rGTPDXCUJW1ya71+W9mUhRODI3vUpzr/0rc2/p6kC4rzFq
/NESfDkrGX/RRdUBWvgpHJAv7Y97TRW3z9oWTtA+SbTiAfCtvqOaeSdXoiTT
DuVoUTQhoUSESnFpj5NJSfIEffHS+Jxwaf/7ZFh/bcp6Opq1x3KUyTrJCkby
d5O3/bQmVJD9gdQBqCyqXWnR0KKT6COTgNFgAx33Es/DFTPdT0DSUUMvlQ0X
cAMXicPg/q6sJBUfV81Hq/KwHe+s7QKHyHi6PzTgxQ3DlE0uWtx3ZRUTF+Dr
ycshYauZJ0in5JEMeq0fBJbiiUhlctcotlrSCq0ZkcAAaUmdEZp+qPt0CZZQ
O9k2lsWLQAMr6aUcFB035YXojiZ10a45Zd0q7PdCuil0JSGi25tXL8M1Ax4o
PmEqQmHKORUwzDbkEvxFnUuYDQnl8QhQblgvdH5H65+HK+Q8PAyX77PsE/Hv
kL1GtxaGG/qSD+VvBOgCZPybBAvb0Nc2+k7Ujs1pIhWHkuMk2HQlt/vBHXJq
P4HUMA/iQ2pOr47++AdR+86BH07lL4HOGydXzm/tRr1r9G6qzpAmgNOV+qvh
phai9xOZsFK3a7fxFM0fGnunfrNlYaZZ8gdFHOXvdAMP+GjsQieNOd+tVjL7
kWS0BHKR5ph0/x+n5G2tMjgAAA==

-->
</rfc>