Changeset 1903

Timestamp:

18/09/12 07:53:38 (10 years ago)

Author:

fielding@…

Message:

https requires and end-to-end secured connection. Addresses #383

Refer just to TLS, not SSL/TLS.

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (9 diffs)
• p1-messaging.xml (modified) (5 diffs)

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires March 21, 2013"; 
+       content: "Expires March 22, 2013"; 
   } 
   @bottom-right {
@@ -492 +492 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-09-17">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-09-18">
       <meta name="dct.replaces" content="urn:ietf:rfc:2145">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
@@ -524 +524 @@
             </tr>
             <tr>
-               <td class="left">Expires: March 21, 2013</td>
+               <td class="left">Expires: March 22, 2013</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">September 17, 2012</td>
+               <td class="right">September 18, 2012</td>
             </tr>
          </tbody>
@@ -556 +556 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on March 21, 2013.</p>
+      <p>This Internet-Draft will expire on March 22, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1081 +1081 @@
       <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
          delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol
-         would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for servers that require
-         an SSL/TLS transport layer on a connection. Other protocols might also be used to provide access to "http" identified resources
+         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.
       </p>
@@ -1095 +1095 @@
       <div id="rfc.iref.u.4"></div>
       <p id="rfc.section.2.7.2.p.1">The "https" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical
-         namespace governed by a potential HTTP origin server listening for SSL/TLS-secured connections on a given TCP port.
+         namespace governed by a potential HTTP origin server listening to a given TCP port for TLS-secured connections <a href="#RFC5246" id="rfc.xref.RFC5246.2"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>.
       </p>
       <p id="rfc.section.2.7.2.p.2">All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that a default
-         TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured through the use of strong encryption prior to sending the first HTTP request.
+         TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured, end-to-end, through the use of strong encryption prior to sending the first HTTP request.
       </p>
       <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.25"></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> ]
@@ -1790 +1790 @@
          effective request URI is constructed as follows.
       </p>
-      <p id="rfc.section.5.5.p.4">If the request is received over an SSL/TLS-secured TCP connection, then the effective request URI's scheme is "https"; otherwise,
+      <p id="rfc.section.5.5.p.4">If the request is received over a TLS-secured TCP connection, then the effective request URI's scheme is "https"; otherwise,
          the scheme is "http".
       </p>
@@ -1810 +1810 @@
       <p>has an effective request URI of</p>  <pre class="text">http://www.example.org:8080/pub/WWW/TheProject.html
 </pre> <div id="rfc.figure.u.49"></div> 
-      <p>Example 2: the following message received over an SSL/TLS-secured TCP connection</p>  <pre class="text">OPTIONS * HTTP/1.1
+      <p>Example 2: the following message received over a TLS-secured TCP connection</p>  <pre class="text">OPTIONS * HTTP/1.1
 Host: www.example.org
 </pre> <div id="rfc.figure.u.50"></div> 
@@ -3737 +3737 @@
                      </ul>
                   </li>
-                  <li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">2.3</a>, <a href="#RFC5246"><b>10.2</b></a></li>
+                  <li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">2.3</a>, <a href="#rfc.xref.RFC5246.2">2.7.2</a>, <a href="#RFC5246"><b>10.2</b></a></li>
                   <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">2.1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">5.7</a>, <a href="#RFC5322"><b>10.2</b></a><ul>
                         <li><em>Section 3.6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">5.7</a></li>

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

@@ -886 +886 @@
    An HTTP service based on some other underlying connection protocol
    would presumably be identified using a different URI scheme, just as
-   the "https" scheme (below) is used for servers that require an SSL/TLS
-   transport layer on a connection. Other protocols might also be used to
+   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
@@ -916 +916 @@
    The "https" URI scheme is hereby defined for the purpose of minting
    identifiers according to their association with the hierarchical
-   namespace governed by a potential HTTP origin server listening for
-   SSL/TLS-secured connections on a given TCP port.
+   namespace governed by a potential HTTP origin server listening to a
+   given TCP port for TLS-secured connections <xref target="RFC5246"/>.
 </t>
 <t>
@@ -923 +923 @@
    requirements for the "https" scheme, except that a default TCP port
    of 443 is assumed if the port subcomponent is empty or not given,
-   and the TCP connection &MUST; be secured through the
+   and the TCP connection &MUST; be secured, end-to-end, through the
    use of strong encryption prior to sending the first HTTP request.
 </t>
@@ -2362 +2362 @@
 </t>
 <t>
-   If the request is received over an SSL/TLS-secured TCP connection,
+   If the request is received over a TLS-secured TCP connection,
    then the effective request URI's scheme is "https"; otherwise, the
    scheme is "http".
@@ -2405 +2405 @@
 <figure>
 <preamble>
-   Example 2: the following message received over an SSL/TLS-secured TCP
-   connection
+   Example 2: the following message received over a TLS-secured TCP connection
 </preamble> 
 <artwork type="example" x:indent-with="  ">