rfc8820xml2.original.xml   rfc8820.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 --> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!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"?>
<rfc ipr="trust200902" docName="draft-nottingham-rfc7320bis-03" category="bcp" o <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
bsoletes="7320" updates="3986"> docName="draft-nottingham-rfc7320bis-03" number="8820" category="bcp"
obsoletes="7320" updates="3986" submissionType="IETF" consensus="true"
xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 2.45.0 -->
<front> <front>
<title>URI Design and Ownership</title> <title>URI Design and Ownership</title>
<seriesInfo name="RFC" value="8820"/>
<seriesInfo name="BCP" value="190"/>
<author initials="M." surname="Nottingham" fullname="Mark Nottingham"> <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
<organization></organization> <organization/>
<address> <address>
<email>mnot@mnot.net</email> <email>mnot@mnot.net</email>
<uri>https://www.mnot.net/</uri> <uri>https://www.mnot.net/</uri>
</address> </address>
</author> </author>
<date month="June" year="2020"/>
<date year="2020"/>
<area>art</area> <area>art</area>
<keyword>URI structure</keyword> <keyword>URI structure</keyword>
<abstract> <abstract>
<!-- Quoted text is DNE. -->
<t>Section 1.1.1 of RFC 3986 defines URI syntax as “a federated and extensible n <t>Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and
aming system wherein extensible naming system wherein each scheme's specification may further
each scheme’s specification may further restrict the syntax and semantics of ide restrict the syntax and semantics of identifiers using that scheme." In
ntifiers using that other words, the structure of a URI is defined by its scheme. While it
scheme.” In other words, the structure of a URI is defined by its scheme. While is common for schemes to further delegate their substructure to the
it is common for URI's owner, publishing independent standards that mandate particular
schemes to further delegate their substructure to the URI’s owner, publishing in forms of substructure in URIs is often problematic.</t>
dependent standards <t>This document provides guidance on the specification of URI
that mandate particular forms of substructure in URIs is often problematic.</t> substructure in standards.</t>
<t>This document obsoletes RFC 7320 and updates RFC 3986.</t>
<t>This document provides guidance on the specification of URI substructure in s
tandards.</t>
</abstract> </abstract>
<note title="Note to Readers">
<t><spanx style="emph">RFC EDITOR: please remove this section and the “URIs” sec
tion before the Appendices before publication</spanx></t>
<t>This is a proposed revision of RFC7320, aka BCP190. The -00 draft is a copy o
f the published RFC;
subsequent revisions will update it.</t>
<t>The issues list for this draft can be found at <eref target="https://github.c
om/mnot/I-D/labels/rfc7320bis">https://github.com/mnot/I-D/labels/rfc7320bis</er
ef>.</t>
<t>The most recent (often, unpublished) draft is at <eref target="https://mnot.g
ithub.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/commit
s/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/">htt
ps://datatracker.ietf.org/doc/draft-nottingham-rfc7320bis/</eref>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<t>URIs <xref 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>
<section anchor="intro" title="Introduction"> <t>Implementations can impose further constraints upon the structure of
URIs; for example, many web servers use the filename extension of the
<t>URIs <xref target="RFC3986"/> very often include structured application data. last path segment to determine the media type of the response. Likewise,
This might include artifacts prepackaged applications often have highly structured URIs that can only
from filesystems (often occurring in the path component) and user information (o be changed in limited ways (often, just the hostname and port on which
ften in the query they are deployed).</t>
component). In some cases, there can even be application-specific data in the au <t>Because the owner of the URI (as defined in <xref target="webarch" form
thority component at="default"/>, Section 2.2.2.1) is choosing to use the
(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; fo
r example, many Web
servers use the filename extension of the last path segment to determine the med
ia type of the
response. Likewise, prepackaged applications often have highly structured URIs t
hat can only be
changed in limited ways (often, just the hostname and port on which they are dep
loyed).</t>
<t>Because the owner of the URI (as defined in <xref target="webarch"/> Section
2.2.2.1) is choosing to use the
server or the application, this can be seen as reasonable delegation of authorit y. However, when server or the application, this can be seen as reasonable delegation of authorit y. However, when
such conventions are mandated by a party other than the owner, it can have sever al potentially such conventions are mandated by a party other than the owner, it can have sever al potentially
detrimental effects:</t> detrimental effects:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Collisions - As more ad hoc conventions for URI structure become sta
<t>Collisions - As more ad hoc conventions for URI structure become standardiz ndardized, it becomes more
ed, it becomes more
likely that there will be collisions between them (especially considering that s ervers, likely that there will be collisions between them (especially considering that s ervers,
applications, and individual deployments will have their own conventions).</t> applications, and individual deployments will have their own conventions).</li>
<t>Dilution - When the information added to a URI is ephemeral, this dilutes i <li>Dilution - When the information added to a URI is ephemeral, this di
ts utility by reducing lutes its utility by reducing
its stability (see <xref target="webarch"/> Section 3.5.1), and can cause severa its stability (see <xref target="webarch" format="default"/>, Section 3.5.1) and
l alternate forms of the URI can cause several alternate forms of the URI
to exist (see <xref target="webarch"/> Section 2.3.1).</t> to exist (see <xref target="webarch" format="default"/>, Section 2.3.1).</li>
<t>Rigidity - Fixed URI syntax often interferes with desired deployment patter <li>Rigidity - Fixed URI syntax often interferes with desired deployment
ns. For example, if an patterns. For example, if an
authority wishes to offer several applications on a single hostname, it becomes difficult to 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> impossible to do if their URIs do not allow the required flexibility.</li>
<t>Operational Difficulty - Supporting some URI conventions can be difficult i <li>Operational Difficulty - Supporting some URI conventions can be diff
n some icult in some
implementations. For example, specifying that a particular query parameter be us implementations. For example, specifying that a particular query parameter be us
ed with “HTTP” ed with "http"
URIs can preclude the use of Web servers that serve the response from a filesyst URIs can preclude the use of web servers that serve the response from a filesyst
em. Likewise, an em. Likewise, an
application that fixes a base path for its operation (e.g., “/v1”) makes it impo application that fixes a base path for its operation (e.g., "/v1") makes it impo
ssible to deploy ssible to deploy
other applications with the same prefix on the same host.</t> other applications with the same prefix on the same host.</li>
<t>Client Assumptions - When conventions are standardized, some clients will i <li>Client Assumptions - When conventions are standardized, some clients
nevitably assume that will inevitably assume that
the standards are in use when those conventions are seen. This can lead to inter operability the standards are in use when those conventions are seen. This can lead to inter operability
problems; for example, if a specification documents that the “sig” URI query par problems; for example, if a specification documents that the "sig" URI query par
ameter indicates ameter indicates
that its payload is a cryptographic signature for the URI, it can lead to undesi that its payload is a cryptographic signature for the URI, it can lead to undesi
rable behavior.</t> rable behavior.</li>
</list></t> </ul>
<t>Publishing a standard that constrains an existing URI structure in ways
<t>Publishing a standard that constrains an existing URI structure in ways that that aren't explicitly
aren’t explicitly allowed by <xref target="RFC3986" format="default"/> (usually, by updating the U
allowed by <xref target="RFC3986"/> (usually, by updating the URI scheme definit RI scheme definition) is therefore sometimes
ion) is therefore sometimes problematic, both for these reasons and because the structure of a URI needs to
problematic, both for these reasons, and because the structure of a URI needs to be firmly under
be firmly under
the control of its owner.</t> the control of its owner.</t>
<t>This document explains some best current practices for establishing URI
<t>This document explains some best current practices for establishing URI struc structures, conventions, and
tures, conventions, and formats in standards. It also offers strategies for specifications in <xref targ
formats in standards. It also offers strategies for specifications in <xref targ et="alternatives" format="default"/>.</t>
et="alternatives"/>.</t> <section anchor="intended-audience" numbered="true" toc="default">
<name>Intended Audience</name>
<section anchor="intended-audience" title="Intended Audience"> <t>This document's guidelines and requirements target the authors of spe
cifications that constrain the
<t>This document’s guidelines and requirements target the authors of specificati
ons that constrain the
syntax or structure of URIs or parts of them. Two classes of such specifications are called out syntax or structure of URIs or parts of them. Two classes of such specifications are called out
specifically:</t> specifically:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Protocol Extensions ("Extensions") - specifications that offer new
<t>Protocol Extensions (“Extensions”) - specifications that offer new capabili capabilities that could apply
ties that could apply to any identifier or to a large subset of possible identifiers, e.g., a new sign
to any identifier, or to a large subset of possible identifiers; e.g., a new sig ature mechanism
nature mechanism for "http" URIs, metadata for any URI, or a new format.</li>
for ‘http’ URIs, metadata for any URI, or a new format.</t> <li>Applications Using URIs ("Applications") - specifications that
<t>Applications Using URIs (“Applications”) - specifications that use URIs to use URIs to meet specific needs,
meet specific needs; e.g., an HTTP interface to particular information on a host.</li>
e.g., an HTTP interface to particular information on a host.</t> </ul>
</list></t> <t>Requirements that target the generic class "Specifications" apply to
all specifications, including
<t>Requirements that target the generic class “Specifications” apply to all spec
ifications, including
both those enumerated above and others.</t> both those enumerated above and others.</t>
<t>Note that this specification ought not be interpreted as preventing t
<t>Note that this specification ought not be interpreted as preventing the alloc he allocation of control of
ation of control of URIs by parties that legitimately own them or have delegated that ownership; for
URIs by parties that legitimately own them, or have delegated that ownership; fo example, a
r example, a specification might legitimately define the semantics of a URI on IANA's web sit
specification might legitimately define the semantics of a URI on IANA’s Web sit e as part of
e as part of
the establishment of a registry.</t> the establishment of a registry.</t>
<t>There may be existing IETF specifications that already deviate from t
<t>There may be existing IETF specifications that already deviate from the guida he guidance in this document.
nce in this document. In these cases, it is up to the relevant communities (i.e., those of the URI
In these cases, it is up to the relevant communities (i.e., those of the URI sch scheme as well as any relevant community that
eme as well as that produced the specification in question) to determine an appropriate outcome, e.g
which produced the specification in question) to determine an appropriate outcom ., updating
e; e.g., updating the scheme definition or changing the specification.</t>
the scheme definition, or changing the specification.</t> </section>
<section anchor="notational-conventions" numbered="true" toc="default">
</section> <name>Notational Conventions</name>
<section anchor="notational-conventions" title="Notational Conventions"> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
“SHOULD NOT”, "<bcp14>SHOULD NOT</bcp14>",
“RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
be interpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and are to be interpreted as described in BCP&nbsp;14
only when, they appear in all capitals, as <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
shown here.</t> when, they appear in all capitals, as shown here.</t>
</section>
</section> </section>
</section> <section anchor="best-current-practices-for-standardizing-structured-uris" n
<section anchor="best-current-practices-for-standardizing-structured-uris" title umbered="true" toc="default">
="Best Current Practices for Standardizing Structured URIs"> <name>Best Current Practices for Standardizing Structured URIs</name>
<t>This section updates <xref target="RFC3986" format="default"/> by advis
<t>This section updates <xref target="RFC3986"/> by advising Specifications how ing Specifications how they should define structure and
they should define structure and semantics within URIs. Best practices differ, depending on the URI component in
semantics within URIs. Best practices differ depending on the URI component in q question, as
uestion, as
described below.</t> described below.</t>
<section anchor="uri-schemes" numbered="true" toc="default">
<section anchor="uri-schemes" title="URI Schemes"> <name>URI Schemes</name>
<t>Applications and Extensions can require the use of one or more specif
<t>Applications and Extensions can require use of specific URI scheme(s); for ex ic URI schemes; for example, it is perfectly
ample, it is perfectly acceptable to require that an Application support "http" and "https" URIs. Howev
acceptable to require that an Application support ‘http’ and ‘https’ URIs. Howev er, Applications
er, Applications
ought not preclude the use of other URI schemes in the future, unless they are c learly only usable ought not preclude the use of other URI schemes in the future, unless they are c learly only usable
with the nominated schemes.</t> 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) <bcp14>MUST</bcp14> do so by modifying <xref target="BCP35" format
="default"/> (an exceptional circumstance).</t>
</section>
<section anchor="uri-authorities" numbered="true" toc="default">
<name>URI Authorities</name>
<t>Scheme definitions define the presence, format, and semantics of an
authority component in URIs; all other Specifications <bcp14>MUST
NOT</bcp14> constrain or define the structure or the semantics for URI
authorities, unless they update the scheme registration itself or the
structures it relies upon (e.g., DNS name syntax, as defined in <xref
target="RFC1034" sectionFormat="of" section="3.5"/>).
<t>A Specification that defines substructure for URI schemes overall (e.g., a pr </t>
efix or suffix for URI <t>For example, an Extension or Application cannot say that the "foo" pr
scheme names) MUST do so by modifying <xref target="BCP35"/> (an exceptional cir efix in
cumstance).</t> "https://foo_app.example.com" is meaningful or triggers special handling in
URIs, unless they update either the "http" URI scheme or the DNS hostname
</section> syntax.</t>
<section anchor="uri-authorities" title="URI Authorities"> <t>Applications can nominate or constrain the port they use, when applic
able. For example,
<t>Scheme definitions define the presence, format and semantics of an authority
component in URIs; all
other Specifications MUST NOT constrain, or define the structure or the semantic
s for URI
authorities, unless they update the scheme registration itself, or the structure
s it relies upon
(e.g., DNS name syntax, defined in Section 3.5 of <xref target="RFC1034"/>).</t>
<t>For example, an Extension or Application cannot say that the “foo” prefix in
“http://foo_app.example.com” is meaningful or triggers special handling in URIs,
unless they update either the HTTP URI scheme, or the DNS hostname syntax.</t>
<t>Applications can nominate or constrain the port they use, when applicable. Fo
r example,
BarApp could run over port nnnn (provided that it is properly registered).</t> BarApp could run over port nnnn (provided that it is properly registered).</t>
</section>
</section> <section anchor="uri-paths" numbered="true" toc="default">
<section anchor="uri-paths" title="URI Paths"> <name>URI Paths</name>
<t>Scheme definitions define the presence, format, and semantics of a pa
<t>Scheme definitions define the presence, format, and semantics of a path compo th component in URIs, although these are often delegated to the Application(s) i
nent in URIs, although these are often delegated to the application(s) in a give n a given deployment.</t>
n deployment.</t> <t>To avoid collisions, rigidity, and erroneous client assumptions, Spec
ifications <bcp14>MUST NOT</bcp14> define a
<t>To avoid collisions, rigidity, and erroneous client assumptions, Specificatio fixed prefix for their URI paths -- for example, "/myapp" -- unless allowed by t
ns MUST NOT define a he scheme definition.</t>
fixed prefix for their URI paths; for example, “/myapp”, unless allowed by the s <t>One such exception to this requirement is registered "well-known" URI
cheme definition.</t> s, as specified by
<xref target="RFC8615" format="default"/>. See that document for a description o
<t>One such exception to this requirement is registered “well-known” URIs, as sp f the applicability of that mechanism.</t>
ecified by <t>Note that this does not apply to Applications defining a structure
<xref target="RFC8615"/>. See that document for a description of the applicabili of a URI's path "under" a resource
ty of that mechanism.</t>
<t>Note that this does not apply to Applications defining a structure of URIs pa
ths “under” a resource
controlled by the server. Because the prefix is under control of the party deplo ying the controlled by the server. Because the prefix is under control of the party deplo ying the
application, collisions and rigidity are avoided, and the risk of erroneous clie nt assumptions is Application, collisions and rigidity are avoided, and the risk of erroneous clie nt assumptions is
reduced.</t> reduced.</t>
<t>For example, an Application might define "app_root" as a deployment-c
<t>For example, an Application might define “app_root” as a deployment-controlle ontrolled URI prefix.
d URI prefix. Application-defined resources might then be assumed to be present at "{app_root}
Application-defined resources might then be assumed to be present at “{app_root} /foo" and
/foo” and "{app_root}/bar".</t>
“{app_root}/bar”.</t> <t>Extensions <bcp14>MUST NOT</bcp14> define a structure within individu
al URI components (e.g., a prefix or suffix),
<t>Extensions MUST NOT define a structure within individual URI components (e.g.
, a prefix or suffix),
again to avoid collisions and erroneous client assumptions.</t> again to avoid collisions and erroneous client assumptions.</t>
</section>
</section> <section anchor="uri-queries" numbered="true" toc="default">
<section anchor="uri-queries" title="URI Queries"> <name>URI Queries</name>
<t>The presence, format, and semantics of the query component of URIs ar
<t>The presence, format and semantics of the query component of URIs is dependen e dependent upon many factors
t upon many factors,
and can be constrained by a scheme definition. Often, they are determined by the implementation of and can be constrained by a scheme definition. Often, they are determined by the implementation of
a resource itself.</t> a resource itself.</t>
<t>Applications can specify the syntax of queries for the resources unde
<t>Applications can specify the syntax of queries for the resources under their r their control. However,
control. However,
doing so can cause operational difficulties for deployments that do not support a particular form 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 ” files that do not of a query. For example, a site may wish to support an Application using "static " files that do not
support query parameters.</t> support query parameters.</t>
<t>Extensions <bcp14>MUST NOT</bcp14> constrain the format or semantics
<t>Extensions MUST NOT constrain the format or semantics of queries, to avoid co of queries, to avoid collisions and erroneous
llisions and erroneous
client assumptions. For example, an Extension that indicates that all query para meters with the client assumptions. For example, an Extension that indicates that all query para meters with the
name “sig” indicate a cryptographic signature would collide with potentially pre existing query name "sig" indicate a cryptographic signature would collide with potentially pre existing query
parameters on sites and lead clients to assume that any matching query parameter is a signature.</t> parameters on sites and lead clients to assume that any matching query parameter is a signature.</t>
<t>Per the "Form submission" section of <xref target="HTML5"/>, HTML con
<t>HTML <xref target="W3C.REC-html401-19991224"/> constrains the syntax of query strains the syntax of
strings used in form submission. query strings used in form submission.
New form languages are encouraged to allow creation of a broader variety of URIs 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> (e.g., by allowing the form to create new path components, and so forth).</t>
</section>
</section> <section anchor="uri-fragment-identifiers" numbered="true" toc="default">
<section anchor="uri-fragment-identifiers" title="URI Fragment Identifiers"> <name>URI Fragment Identifiers</name>
<t><xref target="RFC3986" sectionFormat="of" section="3.5"/> specifies f
<t>Section 3.5 of <xref target="RFC3986"/> specifies fragment identifiers’ synta ragment identifiers' syntax and semantics as being dependent
x and semantics as being dependent upon the media type of a potentially retrieved resource. As a result, other Spec
upon the media type of a potentially retrieved resource. As a result, other Spec ifications <bcp14>MUST NOT</bcp14>
ifications MUST NOT
define structure within the fragment identifier, unless they are explicitly defi ning one for reuse define structure within the fragment identifier, unless they are explicitly defi ning one for reuse
by media types in their definitions (for example, as JSON Pointer <xref target=" by media types in their definitions (for example, as JSON Pointer <xref target="
RFC6901"/> does).</t> RFC6901" format="default"/> does).</t>
<t>An Application that defines common fragment identifiers across media
<t>An Application that defines common fragment identifiers across media types no types not
t
controlled by it would engender interoperability problems with handlers for thos e media types controlled by it would engender interoperability problems with handlers for thos e media types
(because the new, non-standard syntax is not expected).</t> (because the new, non-standard syntax is not expected).</t>
</section>
</section> </section>
</section> <section anchor="alternatives" numbered="true" toc="default">
<section anchor="alternatives" title="Alternatives to Specifying Structure in UR <name>Alternatives to Specifying Structure in URIs</name>
Is"> <t>Given the issues described in <xref target="intro" format="default"/>,
the most successful strategy for Applications and
<t>Given the issues described in <xref target="intro"/>, the most successful str Extensions that wish to use URIs is to use them in the fashion for which they we
ategy for Applications and re designed: as links that
Extensions that wish to use URIs is to use them in the fashion they were designe
d: as links that
are exchanged as part of the protocol, rather than statically specified syntax. Several existing are exchanged as part of the protocol, rather than statically specified syntax. Several existing
specifications can aid in this.</t> specifications can aid in this.</t>
<t><xref target="RFC8288" format="default"/> specifies relation types for
<t><xref target="RFC8288"/> specifies relation types for Web links. By providing web links. By providing a framework for linking on the
a framework for linking on the Web, where every link has a relation type, context, and target, it allows Applic
Web, where every link has a relation type, context and target, it allows Applica ations to define a
tions to define a link's semantics and connectivity.</t>
link’s semantics and connectivity.</t> <t><xref target="RFC6570" format="default"/> provides a standard syntax fo
r URI Templates that can be used to dynamically insert
<t><xref target="RFC6570"/> provides a standard syntax for URI Templates that ca
n be used to dynamically insert
Application-specific variables into a URI to enable such Applications while avoi ding impinging upon Application-specific variables into a URI to enable such Applications while avoi ding impinging upon
URI owners’ control of them.</t> URI owners' control of them.</t>
<t><xref target="RFC8615" format="default"/> allows specific paths to be "
<t><xref target="RFC8615"/> allows specific paths to be ‘reserved’ for standard reserved" for standard use on URI schemes that opt into
use on URI schemes that opt into that mechanism ("http" and "https" by default). Note, however, that this is not
that mechanism (‘http’ and ‘https’ by default). Note, however, that this is not a general "escape
a general “escape valve" for Applications that need structured URIs; see that specification for mo
valve” for applications that need structured URIs; see that specification for mo re information.</t>
re information.</t> <t>Specifying more elaborate structures in an attempt to avoid collisions
is not an acceptable
<t>Specifying more elaborate structures in an attempt to avoid collisions is not solution and does not address the issues described in <xref target="intro" forma
an acceptable t="default"/>. For example, prefixing query parameters
solution, and does not address the issues in <xref target="intro"/>. For example with "myapp_" does not help, because the prefix itself is subject to the risk of
, prefixing query parameters collision (since
with “myapp_” does not help, because the prefix itself is subject to the risk of it is not "reserved").</t>
collision (since </section>
it is not “reserved”).</t> <section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name>
</section> <t>This document does not introduce new protocol artifacts with security c
<section anchor="security-considerations" title="Security Considerations"> onsiderations. It prohibits
<t>This document does not introduce new protocol artifacts with security conside
rations. It prohibits
some practices that might lead to vulnerabilities; for example, if a security-se nsitive mechanism some practices that might lead to vulnerabilities; for example, if a security-se nsitive mechanism
is introduced by assuming that a URI path component or query string has a partic ular meaning, false is introduced by assuming that a URI path component or query string has a partic ular meaning, false
positives might be encountered (due to sites that already use the chosen string) . See also positives might be encountered (due to sites that already use the chosen string) . See also
<xref target="RFC6943"/>.</t> <xref target="RFC6943" format="default"/>.</t>
</section>
</section> <section anchor="iana-considerations" numbered="true" toc="default">
<section anchor="iana-considerations" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
<t>There are no direct IANA actions specified in this document.</t> </section>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<reference anchor="webarch" target="https://www.w3.org/TR/2004/REC-webar
ch-20041215">
<front>
<title>Architecture of the World Wide Web, Volume One</title>
<author initials="I." surname="Jacobs" fullname="Ian Jacobs">
<organization/>
</author>
<author initials="N." surname="Walsh" fullname="Norman Walsh">
<organization/>
</author>
<date year="2004" 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>
<references title='Normative References'> <reference anchor="BCP35" target="https://www.rfc-editor.org/info/bcp35"
>
<reference anchor="webarch" target="http://www.w3.org/TR/2004/REC-webarch-200412 <front>
15"> <title>Guidelines and Registration Procedures for New URI Schemes</t
<front> itle>
<title>Architecture of the World Wide Web, Volume One</title> <author initials="D." surname="Thaler" fullname="Dave Thaler" role="
<author initials="I." surname="Jacobs" fullname="Ian Jacobs"> editor">
<organization></organization> <organization/>
</author> </author>
<author initials="N." surname="Walsh" fullname="Norman Walsh"> <author initials="T." surname="Hansen" fullname="Tony Hansen">
<organization></organization> <organization/>
</author> </author>
<date year="2004" month="December" day="15"/> <author initials="T." surname="Hardie" fullname="Ted Hardie">
</front> <organization/>
</reference> </author>
<date year="2015" month="June"/>
<reference anchor="RFC3986" target='https://www.rfc-editor.org/info/rfc3986'> </front>
<front> <seriesInfo name="BCP" value="35"/>
<title>Uniform Resource Identifier (URI): Generic Syntax</title> <seriesInfo name="RFC" value="7595"/>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organizat </reference>
ion /></author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization />
</author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization />
</author>
<date year='2005' month='January' />
<abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of charac
ters that identifies an abstract or physical resource. This specification defin
es 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 u
se 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 possi
ble identifier. This specification does not define a generative grammar for URI
s; that task is performed by the individual specifications of each URI scheme.
[STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/>
<seriesInfo name='DOI' value='10.17487/RFC3986'/>
</reference>
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></
author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify
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 Comm
unity, 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 /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</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'><organ
ization /></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 us
ed for host address look up and electronic mail forwarding. It discusses the cl
ients 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'><organizatio
n /></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) sche
mes.</t><t>In doing so, it obsoletes RFC 5785 and updates the URI schemes define
d in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI sche
mes 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-1
9991224' />
<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'><organiz
ation /></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 val
ue 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'><organizatio
n /></author>
<date year='2017' month='October' />
<abstract><t>This specification defines a model for the relationships between re
sources on the Web (&quot;links&quot;) and the type of those relationships (&quo
t;link relation types&quot;).</t><t>It also defines the serialisation of such li
nks 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'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.
<front> xml"/>
<title>URI Template</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8615.
<author initials='J.' surname='Gregorio' fullname='J. Gregorio'><organization /> xml"/>
</author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization />
</author>
<author initials='M.' surname='Hadley' fullname='M. Hadley'><organization /></au
thor>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organizatio
n /></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 specific
ation defines the URI Template syntax and the process for expanding a URI Templa
te into a URI reference, along with guidelines for the use of URI Templates on t
he 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'> <reference anchor="HTML5" target="https://html.spec.whatwg.org/#form-submi
<front> ssion">
<title>Issues in Identifier Comparison for Security Purposes</title> <front>
<author initials='D.' surname='Thaler' fullname='D. Thaler' role='editor'><organ <title>HTML - Living Standard</title>
ization /></author> <author>
<date year='2013' month='May' /> <organization>WHATWG</organization>
<abstract><t>Identifiers such as hostnames, URIs, IP addresses, and email addres </author>
ses are often used in security contexts to identify security principals and reso <date month="June" year="2020" />
urces. In such contexts, an identifier presented via some protocol is often com </front>
pared using some policy to make security decisions such as whether the security <refcontent>Section 4.10.21</refcontent>
principal may access the resource, what level of authentication or encryption is </reference>
required, etc. If the parties involved in a security decision use different al
gorithms to compare identifiers, then failure scenarios ranging from denial of s
ervice to elevation of privilege can result. This document provides a discussio
n of these issues that designers should consider when defining identifiers and p
rotocols, and when constructing architectures that use multiple protocols.</t></
abstract>
</front>
<seriesInfo name='RFC' value='6943'/>
<seriesInfo name='DOI' value='10.17487/RFC6943'/>
</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> </references>
<section anchor="changes-from-rfc7320" numbered="true" toc="default">
<section anchor="changes-from-rfc7320" title="Changes from RFC7320"> <name>Changes from RFC 7320</name>
<t>Many of the requirements of RFC 7320 were removed, in the spirit of mak
<t>Many of the requirements of RFC7320 were removed, in the spirit of making thi ing this BCP guidance rather than rules.</t>
s BCP guidance, rather than rules.</t> </section>
<section anchor="acknowledgments" numbered="false" toc="default">
</section> <name>Acknowledgments</name>
<section anchor="acknowledgments" title="Acknowledgments"> <t>Thanks to <contact fullname="David Booth"/>, <contact fullname="Dave
Crocker"/>, <contact fullname="Tim Bray"/>, <contact fullname="Anne van
<t>Thanks to David Booth, Dave Crocker, Tim Bray, Anne van Kesteren, Martin Thom Kesteren"/>, <contact fullname="Martin Thomson"/>, <contact
son, Erik Wilde, fullname="Erik Wilde"/>, <contact fullname="Dave Thaler"/>, and <contact
Dave Thaler and Barry Leiba for their suggestions and feedback.</t> fullname="Barry Leiba"/> for their suggestions and feedback.</t>
</section>
</section>
</back> </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> </rfc>
 End of changes. 47 change blocks. 
701 lines changed or deleted 328 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/