Changeset 2150 for draft-ietf-httpbis/latest

Timestamp:

23/01/13 10:21:37 (10 years ago)

Author:

fielding@…

Message:

(editorial) more cleanup in p5

Location:

draft-ietf-httpbis/latest

Files:

• p5-range.html (modified) (13 diffs)
• p5-range.xml (modified) (11 diffs)

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires July 24, 2013"; 
+       content: "Expires July 27, 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-01-20">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-01-23">
       <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: July 24, 2013</td>
+               <td class="left">Expires: July 27, 2013</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -527 +527 @@
             <tr>
                <td class="left"></td>
-               <td class="right">January 20, 2013</td>
+               <td class="right">January 23, 2013</td>
             </tr>
          </tbody>
@@ -552 +552 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on July 24, 2013.</p>
+      <p>This Internet-Draft will expire on July 27, 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>
@@ -670 +670 @@
   <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a>  = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
   <a href="#rule.ranges-specifier" class="smpl">last-byte-pos</a>   = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
-</pre><p id="rfc.section.2.1.p.5">The first-byte-pos value in a byte-range-spec gives the byte-offset of the first byte in a range. The last-byte-pos value
-         gives the byte-offset of the last byte in the range; that is, the byte positions specified are inclusive. Byte offsets start
-         at zero.
-      </p>
-      <p id="rfc.section.2.1.p.6">Examples of byte-ranges-specifier values: </p>
+</pre><p id="rfc.section.2.1.p.5">The <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a> value in a <a href="#rule.ranges-specifier" class="smpl">byte-range-spec</a> gives the byte-offset of the first byte in a range. The <a href="#rule.ranges-specifier" class="smpl">last-byte-pos</a> value gives the byte-offset of the last byte in the range; that is, the byte positions specified are inclusive. Byte offsets
+         start at zero.
+      </p>
+      <p id="rfc.section.2.1.p.6">Examples of <a href="#rule.ranges-specifier" class="smpl">byte-ranges-specifier</a> values: 
+      </p>
       <ul>
          <li>The first 500 bytes (byte offsets 0-499, inclusive): 
@@ -683 +683 @@
 </pre> </li>
       </ul>
-      <p id="rfc.section.2.1.p.7">If the last-byte-pos value is present, it <em class="bcp14">MUST</em> be greater than or equal to the first-byte-pos in that byte-range-spec, or the byte-range-spec is syntactically invalid. The
-         recipient of a byte-range-set that includes one or more syntactically invalid byte-range-spec values <em class="bcp14">MUST</em> ignore the header field that includes that byte-range-set.
-      </p>
-      <p id="rfc.section.2.1.p.8">If the last-byte-pos value is absent, or if the value is greater than or equal to the current length of the representation
-         data, last-byte-pos is taken to be equal to one less than the current length of the representation in bytes.
-      </p>
-      <p id="rfc.section.2.1.p.9">By its choice of last-byte-pos, a client can limit the number of bytes retrieved without knowing the size of the representation.</p>
+      <p id="rfc.section.2.1.p.7">A <a href="#rule.ranges-specifier" class="smpl">byte-range-spec</a> is invalid if the <a href="#rule.ranges-specifier" class="smpl">last-byte-pos</a> value is present and less than the <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a>.
+      </p>
+      <p id="rfc.section.2.1.p.8">A client can limit the number of bytes requested without knowing the size of the selected representation. If the <a href="#rule.ranges-specifier" class="smpl">last-byte-pos</a> value is absent, or if the value is greater than or equal to the current length of the representation data, the byte range
+         is interpreted as the remainder of the representation (i.e., the server replaces the value of <a href="#rule.ranges-specifier" class="smpl">last-byte-pos</a> with a value that is one less than the current length of the selected representation).
+      </p>
+      <p id="rfc.section.2.1.p.9">A client can request the last N bytes of the selected representation using a <a href="#rule.ranges-specifier" class="smpl">suffix-byte-range-spec</a>.
+      </p>
       <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">A suffix-byte-range-spec is used to specify the suffix of the representation data, of a length given by the suffix-length
-         value. (That is, this form specifies the last N bytes of a representation.) If the representation is shorter than the specified
-         suffix-length, the entire representation is used. For example (assuming a representation of length 10000): 
+</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>
       <ul>
@@ -709 +707 @@
 </pre> </li>
       </ul>
-      <p id="rfc.section.2.1.p.12">If a syntactically valid byte-range-set includes at least one byte-range-spec whose first-byte-pos is less than the current
-         length of the representation, or at least one suffix-byte-range-spec with a non-zero suffix-length, then the byte-range-set
-         is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> send a response with a <a href="#status.416" class="smpl">416 (Range Not Satisfiable)</a> status code. Otherwise, the server <em class="bcp14">SHOULD</em> send a response with a <a href="#status.206" class="smpl">206 (Partial Content)</a> status code containing the satisfiable ranges of the representation.
-      </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 <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows.
+      <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
+         to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows.
       </p>
       <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="range.units.other" href="#range.units.other">Other Range Units</a></h2>
@@ -721 +718 @@
 </pre><div id="rfc.iref.a.1"></div>
       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="header.accept-ranges" href="#header.accept-ranges">Accept-Ranges</a></h2>
-      <p id="rfc.section.2.3.p.1">The "Accept-Ranges" header field allows a resource to indicate its acceptance of range requests.</p>
+      <p id="rfc.section.2.3.p.1">The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.</p>
       <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span>  <a href="#header.accept-ranges" class="smpl">Accept-Ranges</a>     = <a href="#header.accept-ranges" class="smpl">acceptable-ranges</a>
   <a href="#header.accept-ranges" class="smpl">acceptable-ranges</a> = 1#<a href="#range.units" class="smpl">range-unit</a> / "none"
-</pre><p id="rfc.section.2.3.p.3">Origin servers that accept byte-range requests <em class="bcp14">MAY</em> send
+</pre><p id="rfc.section.2.3.p.3">Origin servers that support byte-range requests <em class="bcp14">MAY</em> send
       </p>
       <div id="rfc.figure.u.13"></div><pre class="text">  Accept-Ranges: bytes
 </pre><p id="rfc.section.2.3.p.5">but are not required to do so. Clients <em class="bcp14">MAY</em> generate range requests without having received this header field for the resource involved. Range units are defined in <a href="#range.units" title="Range Units">Section&nbsp;2</a>.
       </p>
-      <p id="rfc.section.2.3.p.6">Servers that do not accept any kind of range request for a resource <em class="bcp14">MAY</em> send
+      <p id="rfc.section.2.3.p.6">Servers that do not support any kind of range request for the target resource resource <em class="bcp14">MAY</em> send
       </p>
       <div id="rfc.figure.u.14"></div><pre class="text">  Accept-Ranges: none
@@ -736 +733 @@
       <div id="rfc.iref.r.1"></div>
       <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="header.range" href="#header.range">Range</a></h2>
-      <p id="rfc.section.3.1.p.1">The "Range" header field on a GET request modifies the method semantics to request transfer of only one or more sub-ranges
-         of the selected representation data in a successful response, rather than the entire representation data.
+      <p id="rfc.section.3.1.p.1">The "Range" header field on a GET request modifies the method semantics to request transfer of only one or more subranges
+         of the selected representation data, rather than the entire selected representation data.
       </p>
       <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.16"></span>  <a href="#header.range" class="smpl">Range</a> = <a href="#rule.ranges-specifier" class="smpl">byte-ranges-specifier</a> / <a href="#header.range" class="smpl">other-ranges-specifier</a>
@@ -746 +743 @@
          server <em class="bcp14">MUST</em> ignore a Range header field received with a request method other than GET.
       </p>
-      <p id="rfc.section.3.1.p.4">An origin server <em class="bcp14">MUST</em> ignore a <a href="#header.range" class="smpl">Range</a> header field that contains a range unit it does not understand. A proxy <em class="bcp14">MAY</em> either discard a <a href="#header.range" class="smpl">Range</a> header field that contains a range unit it does not understand or pass it to the next inbound server when forwarding the request.
+      <p id="rfc.section.3.1.p.4">An origin server <em class="bcp14">MUST</em> ignore a Range header field that contains a range unit it does not understand. A proxy <em class="bcp14">MAY</em> either discard a Range header field that contains a range unit it does not understand or pass it to the next inbound server
+         when forwarding the request.
       </p>
       <p id="rfc.section.3.1.p.5">The Range header field is evaluated after evaluating the preconditions of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> and only if the result of their evaluation is leading toward a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response. In other words, Range is ignored when a conditional GET would result in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response.
@@ -752 +750 @@
       <p id="rfc.section.3.1.p.6">The If-Range header field (<a href="#header.if-range" id="rfc.xref.header.if-range.1" title="If-Range">Section&nbsp;3.2</a>) can be used as a precondition to applying the Range header field.
       </p>
-      <p id="rfc.section.3.1.p.7">If all of the preconditions are true, the server supports the Range header field for the target resource, the specified range(s)
-         are syntactically correct (as defined in <a href="#byte.ranges" title="Byte Ranges">Section&nbsp;2.1</a>), and at least one of the ranges has a non-empty intersection with the current selected representation extent, then the server <em class="bcp14">MAY</em> respond with a status code of <a href="#status.206" class="smpl">206 (Partial Content)</a> and a payload containing one or more partial representations that correspond to those requested, as defined in <a href="#range.response" title="Responses to a Range Request">Section&nbsp;4</a>.
+      <p id="rfc.section.3.1.p.7">If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified
+         range(s) are valid and satisfiable (as defined in <a href="#byte.ranges" title="Byte Ranges">Section&nbsp;2.1</a>), the server <em class="bcp14">SHOULD</em> send a <a href="#status.206" class="smpl">206 (Partial Content)</a> response with a payload containing one or more partial representations that correspond to the satisfiable ranges requested,
+         as defined in <a href="#range.response" title="Responses to a Range Request">Section&nbsp;4</a>.
+      </p>
+      <p id="rfc.section.3.1.p.8">If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified
+         range(s) are invalid or unsatisfiable, the server <em class="bcp14">SHOULD</em> send a <a href="#status.416" class="smpl">416 (Range Not Satisfiable)</a> response.
       </p>
       <div id="rfc.iref.i.1"></div>
@@ -771 +773 @@
          validator, if the date value is not strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>. (A server can distinguish between a valid HTTP-date and any form of entity-tag by examining the first two characters.)
       </p>
-      <p id="rfc.section.3.2.p.6">The If-Range header field <em class="bcp14">SHOULD</em> only be sent by clients together with a Range header field. The If-Range header field <em class="bcp14">MUST</em> be ignored if it is received in a request that does not include a Range header field. The If-Range header field <em class="bcp14">MUST</em> be ignored by a server that does not support the sub-range operation.
+      <p id="rfc.section.3.2.p.6">A client <em class="bcp14">MUST NOT</em> generate an If-Range header field in a request that does not contain a <a href="#header.range" class="smpl">Range</a> header field. A server <em class="bcp14">MUST</em> ignore an If-Range header field received in a request that does not contain a <a href="#header.range" class="smpl">Range</a> header field. An origin server <em class="bcp14">MUST</em> ignore an If-Range header field received in a request for a target resource that does not support Range requests.
       </p>
       <p id="rfc.section.3.2.p.7">If the validator given in the If-Range header field matches the current validator for the selected representation of the target
-         resource, then the server <em class="bcp14">SHOULD</em> send the specified sub-range of the representation using a <a href="#status.206" class="smpl">206 (Partial Content)</a> response. If the validator does not match, then the server <em class="bcp14">SHOULD</em> send the entire representation using a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response.
+         resource, then the server <em class="bcp14">SHOULD</em> process the Range header field as requested. If the validator does not match, then the server <em class="bcp14">MUST</em> ignore the <a href="#header.range" class="smpl">Range</a> header field.
       </p>
       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="range.response" href="#range.response">Responses to a Range Request</a></h1>

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

@@ -229 +229 @@
 </artwork></figure>
 <t>
-   The first-byte-pos value in a byte-range-spec gives the byte-offset
-   of the first byte in a range. The last-byte-pos value gives the
-   byte-offset of the last byte in the range; that is, the byte
-   positions specified are inclusive. Byte offsets start at zero.
-</t>
-<t>
-   Examples of byte-ranges-specifier values:
+   The <x:ref>first-byte-pos</x:ref> value in a <x:ref>byte-range-spec</x:ref>
+   gives the byte-offset of the first byte in a range.
+   The <x:ref>last-byte-pos</x:ref> value gives the byte-offset of the last
+   byte in the range; that is, the byte positions specified are inclusive.
+   Byte offsets start at zero.
+</t>
+<t>
+   Examples of <x:ref>byte-ranges-specifier</x:ref> values:
   <list style="symbols">
      <t>The first 500 bytes (byte offsets 0-499, inclusive):
@@ -250 +251 @@
 </t>
 <t>
-   If the last-byte-pos value is present, it &MUST; be greater than or
-   equal to the first-byte-pos in that byte-range-spec, or the byte-range-spec
-   is syntactically invalid. The recipient of a byte-range-set
-   that includes one or more syntactically invalid byte-range-spec
-   values &MUST; ignore the header field that includes that byte-range-set.
-</t>
-<t>
-   If the last-byte-pos value is absent, or if the value is greater than
-   or equal to the current length of the representation data, last-byte-pos is
-   taken to be equal to one less than the current length of the representation
-   in bytes.
-</t>
-<t>
-   By its choice of last-byte-pos, a client can limit the number of
-   bytes retrieved without knowing the size of the representation.
+   A <x:ref>byte-range-spec</x:ref> is invalid if the
+   <x:ref>last-byte-pos</x:ref> value is present and less than the
+   <x:ref>first-byte-pos</x:ref>.
+</t>
+<t>
+   A client can limit the number of bytes requested without knowing the size
+   of the selected representation.
+   If the <x:ref>last-byte-pos</x:ref> value is absent, or if the value is
+   greater than or equal to the current length of the representation data, the
+   byte range is interpreted as the remainder of the representation (i.e., the
+   server replaces the value of <x:ref>last-byte-pos</x:ref> with a value that
+   is one less than the current length of the selected representation).
+</t>
+<t>
+   A client can request the last N bytes of the selected representation using
+   a <x:ref>suffix-byte-range-spec</x:ref>.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="suffix-byte-range-spec"/><iref primary="true" item="Grammar" subitem="suffix-length"/>
@@ -271 +273 @@
 </artwork></figure>
 <t>
-   A suffix-byte-range-spec is used to specify the suffix of the
-   representation data, of a length given by the suffix-length value. (That is,
-   this form specifies the last N bytes of a representation.) If the
-   representation is shorter than the specified suffix-length, the entire
-   representation is used. For example (assuming a representation of
-   length 10000):
+   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):
   <list style="symbols">
      <t>The final 500 bytes (byte offsets 9500-9999, inclusive):
@@ -302 +301 @@
 </t>
 <t>
-   If a syntactically valid byte-range-set includes at least one byte-range-spec
-   whose first-byte-pos is less than the current length of
-   the representation, or at least one suffix-byte-range-spec with a non-zero
-   suffix-length, then the byte-range-set is satisfiable.
-   Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
-   is unsatisfiable, the server &SHOULD; send a response with a 
-   <x:ref>416 (Range Not Satisfiable)</x:ref> status code. Otherwise, the server
-   &SHOULD; send a response with a <x:ref>206 (Partial Content)</x:ref> status code
-   containing the satisfiable ranges of the representation.
+   If a valid <x:ref>byte-range-set</x:ref> includes at least one
+   <x:ref>byte-range-spec</x:ref> with a <x:ref>first-byte-pos</x:ref> that is
+   less than the current length of the representation, or at least one
+   <x:ref>suffix-byte-range-spec</x:ref> with a non-zero
+   <x:ref>suffix-length</x:ref>, then the <x:ref>byte-range-set</x:ref> is
+   satisfiable. Otherwise, the <x:ref>byte-range-set</x:ref> is unsatisfiable.
 </t>
 <t>
    In the byte range syntax, <x:ref>first-byte-pos</x:ref>,
    <x:ref>last-byte-pos</x:ref>, and <x:ref>suffix-length</x:ref> are
-   expressed as decimal number of octets.  Since there is no predefined limit
-   to the length of a payload, recipients &SHOULD; anticipate
-   potentially large decimal numerals and prevent parsing errors due to integer
-   conversion overflows.
+   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.
 </t>
 </section>
@@ -338 +334 @@
   <x:anchor-alias value="acceptable-ranges"/>
 <t>
-   The "Accept-Ranges" header field allows a resource to indicate
-   its acceptance of range requests.
+   The "Accept-Ranges" header field allows a server to indicate that it
+   supports range requests for the target resource.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Ranges"/><iref primary="true" item="Grammar" subitem="acceptable-ranges"/>
@@ -346 +342 @@
 </artwork></figure>
 <t>
-   Origin servers that accept byte-range requests &MAY; send
+   Origin servers that support byte-range requests &MAY; send
 </t>
 <figure><artwork type="example">
@@ -357 +353 @@
 </t>
 <t>
-   Servers that do not accept any kind of range request for a
-   resource &MAY; send
+   Servers that do not support any kind of range request for the target
+   resource resource &MAY; send
 </t>
 <figure><artwork type="example">
@@ -378 +374 @@
 <t>
    The "Range" header field on a GET request modifies the method semantics to
-   request transfer of only one or more sub-ranges of the selected
-   representation data in a successful response, rather than the entire
-   representation data.
+   request transfer of only one or more subranges of the selected
+   representation data, rather than the entire selected representation data.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Range"/>
@@ -395 +390 @@
 </t>
 <t>
-   An origin server &MUST; ignore a <x:ref>Range</x:ref> header field that
-   contains a range unit it does not understand. A proxy &MAY; either discard
-   a <x:ref>Range</x:ref> header field that contains a range unit it does not
-   understand or pass it to the next inbound server when forwarding the
-   request.
+   An origin server &MUST; ignore a Range header field that contains a range
+   unit it does not understand. A proxy &MAY; either discard a Range header
+   field that contains a range unit it does not understand or pass it to the
+   next inbound server when forwarding the request.
 </t>
 <t>
@@ -414 +408 @@
 <t>
    If all of the preconditions are true, the server supports the Range header
-   field for the target resource, the specified range(s) are syntactically
-   correct (as defined in <xref target="byte.ranges"/>), and at least one of
-   the ranges has a non-empty intersection with the current selected
-   representation extent, then the server &MAY; respond with a status code of
-   <x:ref>206 (Partial Content)</x:ref> and a payload containing one or more
-   partial representations that correspond to those requested, as defined in
+   field for the target resource, and the specified range(s) are valid and
+   satisfiable (as defined in <xref target="byte.ranges"/>), the
+   server &SHOULD; send a <x:ref>206 (Partial Content)</x:ref> response with a
+   payload containing one or more partial representations that correspond to
+   the satisfiable ranges requested, as defined in
    <xref target="range.response"/>.
+</t>
+<t>
+   If all of the preconditions are true, the server supports the Range header
+   field for the target resource, and the specified range(s) are invalid or
+   unsatisfiable, the server &SHOULD; send a
+   <x:ref>416 (Range Not Satisfiable)</x:ref> response.
 </t>
 </section>
@@ -462 +461 @@
 </t>
 <t>
-   The If-Range header field &SHOULD; only be sent by clients together with
-   a Range header field.  The If-Range header field &MUST; be ignored if it
-   is received in a request that does not include a Range header field.
-   The If-Range header field &MUST; be ignored by a server that does not
-   support the sub-range operation.
+   A client &MUST-NOT; generate an If-Range header field in a request that
+   does not contain a <x:ref>Range</x:ref> header field.
+   A server &MUST; ignore an If-Range header field received in a request that
+   does not contain a <x:ref>Range</x:ref> header field.
+   An origin server &MUST; ignore an If-Range header field received in a
+   request for a target resource that does not support Range requests.
 </t>
 <t>
    If the validator given in the If-Range header field matches the current
    validator for the selected representation of the target resource, then
-   the server &SHOULD; send the specified sub-range of the representation
-   using a <x:ref>206 (Partial Content)</x:ref> response. If the validator
-   does not match, then the server &SHOULD; send the entire representation
-   using a <x:ref>200 (OK)</x:ref> response.
+   the server &SHOULD; process the Range header field as requested.
+   If the validator does not match, then the server &MUST; ignore the
+   <x:ref>Range</x:ref> header field.
 </t>
 </section>