Changeset 2217 for draft-ietf-httpbis/latest

Timestamp:

31/03/13 16:23:11 (10 years ago)

Author:

julian.reschke@…

Message:

Editorial nits (​http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/1377.html)

Location:

draft-ietf-httpbis/latest

Files:

• p5-range.html (modified) (10 diffs)
• p5-range.xml (modified) (3 diffs)

draft-ietf-httpbis/latest/p5-range.html

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires September 19, 2013"; 
+       content: "Expires October 2, 2013"; 
   } 
   @bottom-right {
@@ -492 +492 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2013-03-18">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-03-31">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.">
@@ -518 +518 @@
             </tr>
             <tr>
-               <td class="left">Expires: September 19, 2013</td>
+               <td class="left">Expires: October 2, 2013</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -527 +527 @@
             <tr>
                <td class="left"></td>
-               <td class="right">March 18, 2013</td>
+               <td class="right">March 31, 2013</td>
             </tr>
          </tbody>
@@ -552 +552 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 19, 2013.</p>
+      <p>This Internet-Draft will expire on October 2, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -634 +634 @@
          or the dimensions of an embedded image.
       </p>
-      <p id="rfc.section.1.p.2">This document defines HTTP/1.1 range requests, partial responses, and the multipart/byteranges media type, obsoleting those
-         parts previously defined in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. Range requests are an <em class="bcp14">OPTIONAL</em> feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource)
+      <p id="rfc.section.1.p.2">This document defines HTTP/1.1 range requests, partial responses, and the multipart/byteranges media type. Range requests
+         are an <em class="bcp14">OPTIONAL</em> feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource)
          can respond as if it is a normal GET request without impacting interoperability. Partial responses are indicated by a distinct
          status code to not be mistaken for full responses by caches that might not implement the feature.
@@ -692 +692 @@
       <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span>  <a href="#rule.ranges-specifier" class="smpl">suffix-byte-range-spec</a> = "-" <a href="#rule.ranges-specifier" class="smpl">suffix-length</a>
   <a href="#rule.ranges-specifier" class="smpl">suffix-length</a> = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
-</pre><p id="rfc.section.2.1.p.11">If the selected representation is shorter than the specified <a href="#rule.ranges-specifier" class="smpl">suffix-length</a>, the entire representation is used. For example (assuming a representation of length 10000): 
-      </p>
+</pre><p id="rfc.section.2.1.p.11">If the selected representation is shorter than the specified <a href="#rule.ranges-specifier" class="smpl">suffix-length</a>, the entire representation is used.
+      </p>
+      <p id="rfc.section.2.1.p.12">Additional examples, assuming a representation of length 10000: </p>
       <ul>
          <li>The final 500 bytes (byte offsets 9500-9999, inclusive): 
@@ -707 +708 @@
 </pre> </li>
       </ul>
-      <p id="rfc.section.2.1.p.12">If a valid <a href="#rule.ranges-specifier" class="smpl">byte-range-set</a> includes at least one <a href="#rule.ranges-specifier" class="smpl">byte-range-spec</a> with a <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a> that is less than the current length of the representation, or at least one <a href="#rule.ranges-specifier" class="smpl">suffix-byte-range-spec</a> with a non-zero <a href="#rule.ranges-specifier" class="smpl">suffix-length</a>, then the <a href="#rule.ranges-specifier" class="smpl">byte-range-set</a> is satisfiable. Otherwise, the <a href="#rule.ranges-specifier" class="smpl">byte-range-set</a> is unsatisfiable.
-      </p>
-      <p id="rfc.section.2.1.p.13">In the byte range syntax, <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a>, <a href="#rule.ranges-specifier" class="smpl">last-byte-pos</a>, and <a href="#rule.ranges-specifier" class="smpl">suffix-length</a> are expressed as decimal number of octets. Since there is no predefined limit to the length of a payload, recipients ought
+      <p id="rfc.section.2.1.p.13">If a valid <a href="#rule.ranges-specifier" class="smpl">byte-range-set</a> includes at least one <a href="#rule.ranges-specifier" class="smpl">byte-range-spec</a> with a <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a> that is less than the current length of the representation, or at least one <a href="#rule.ranges-specifier" class="smpl">suffix-byte-range-spec</a> with a non-zero <a href="#rule.ranges-specifier" class="smpl">suffix-length</a>, then the <a href="#rule.ranges-specifier" class="smpl">byte-range-set</a> is satisfiable. Otherwise, the <a href="#rule.ranges-specifier" class="smpl">byte-range-set</a> is unsatisfiable.
+      </p>
+      <p id="rfc.section.2.1.p.14">In the byte range syntax, <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a>, <a href="#rule.ranges-specifier" class="smpl">last-byte-pos</a>, and <a href="#rule.ranges-specifier" class="smpl">suffix-length</a> are expressed as decimal number of octets. Since there is no predefined limit to the length of a payload, recipients ought
          to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows.
       </p>
@@ -933 +934 @@
 Content-Range: bytes */47022
 </pre><div class="note" id="rfc.section.4.4.p.4"> 
-         <p> <b>Note:</b> Because servers are free to ignore <a href="#header.range" class="smpl">Range</a>, many implementations will simply respond with <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> if the requested ranges are invalid or not satisfiable. That is partly because most clients are prepared to receive a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> to complete the task (albeit less efficiently) and partly because clients might not stop making an invalid partial request
+         <p> <b>Note:</b> Because servers are free to ignore <a href="#header.range" class="smpl">Range</a>, many implementations will simply respond with the entire selected representation in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response if the requested ranges are invalid or not satisfiable. That is partly because most clients are prepared to receive
+            a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> to complete the task (albeit less efficiently) and partly because clients might not stop making an invalid partial request
             until they have received a complete representation. Thus, clients cannot depend on receiving a <a href="#status.416" class="smpl">416 (Range Not Satisfiable)</a> response even when it is most appropriate.
          </p> 
@@ -1448 +1450 @@
                   </li>
                   <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>8.1</b></a></li>
-                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#RFC2616"><b>8.2</b></a></li>
+                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#RFC2616"><b>8.2</b></a></li>
                   <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.1.1</a>, <a href="#RFC5226"><b>8.2</b></a><ul>
                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.1.1</a></li>

draft-ietf-httpbis/latest/p5-range.xml

@@ -141 +141 @@
 <t>
    This document defines HTTP/1.1 range requests, partial responses, and the
-   multipart/byteranges media type, obsoleting those parts previously defined
-   in <xref target="RFC2616"/>. Range requests are an &OPTIONAL; feature
+   multipart/byteranges media type. Range requests are an &OPTIONAL; feature
    of HTTP, designed so that recipients not implementing this feature (or not
    supporting it for the target resource) can respond as if it is a normal
@@ -275 +274 @@
    If the selected representation is shorter than the specified
    <x:ref>suffix-length</x:ref>, the entire representation is used.
-   For example (assuming a representation of length 10000):
+</t>
+<t>   
+   Additional examples, assuming a representation of length 10000:
   <list style="symbols">
      <t>The final 500 bytes (byte offsets 9500-9999, inclusive):
@@ -823 +824 @@
   <t>
     &Note; Because servers are free to ignore <x:ref>Range</x:ref>, many
-    implementations will simply respond with <x:ref>200 (OK)</x:ref> if the
+    implementations will simply respond with the entire selected representation
+    in a <x:ref>200 (OK)</x:ref> response if the
     requested ranges are invalid or not satisfiable. That is partly because
     most clients are prepared to receive a <x:ref>200 (OK)</x:ref> to