Changeset 2278 for draft-ietf-httpbis/latest

Timestamp:

03/06/13 07:15:20 (8 years ago)

Author:

fielding@…

Message:

(editorial) clarify that name delegation for http and https URIs depend on TCP and TLS/TCP, respectively; addresses #447

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (2 diffs)
• p1-messaging.xml (modified) (2 diffs)

draft-ietf-httpbis/latest/p1-messaging.html

@@ -1075 +1075 @@
          would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for resources that
          require an end-to-end secured connection. Other protocols might also be used to provide access to "http" identified resources
-         — it is only the authoritative interface used for mapping the namespace that is specific to TCP.
+         — it is only the authoritative interface that is specific to TCP.
       </p>
       <p id="rfc.section.2.7.1.p.8">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.13"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal
@@ -1093 +1093 @@
       </p>
       <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.26"></span>  <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
-</pre><p id="rfc.section.2.7.2.p.4">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers
-         indicate the same authority (the same host listening to the same TCP port). They are distinct name spaces and are considered
-         to be distinct origin servers. However, an extension to HTTP that is defined to apply to entire host domains, such as the
-         Cookie protocol <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>, can allow information set by one service to impact communication with other services within a matching group of host domains.
+</pre><p id="rfc.section.2.7.2.p.4">Note that the "https" URI scheme depends on both TLS and TCP for establishing authority. Resources made available via the
+         "https" scheme have no shared identity with the "http" scheme even if their resource identifiers indicate the same authority
+         (the same host listening to the same TCP port). They are distinct name spaces and are considered to be distinct origin servers.
+         However, an extension to HTTP that is defined to apply to entire host domains, such as the Cookie protocol <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>, can allow information set by one service to impact communication with other services within a matching group of host domains.
       </p>
       <p id="rfc.section.2.7.2.p.5">The process for authoritative access to an "https" identified resource is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.2"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -893 +893 @@
    end-to-end secured connection. Other protocols might also be used to
    provide access to "http" identified resources — it is only the
-   authoritative interface used for mapping the namespace that is
-   specific to TCP.
+   authoritative interface that is specific to TCP.
 </t>
 <t>
@@ -935 +934 @@
 </artwork></figure>
 <t>
+   Note that the "https" URI scheme depends on both TLS and TCP for
+   establishing authority.
    Resources made available via the "https" scheme have no shared
    identity with the "http" scheme even if their resource identifiers