Ignore:
Timestamp:
20/01/13 16:15:04 (10 years ago)
Author:
fielding@…
Message:

(editorial) clean up p5 intro and range units

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p5-range.xml

    r2143 r2144  
    2323  <!ENTITY whitespace                 "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2424  <!ENTITY field-components           "<xref target='Part1' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    25   <!ENTITY http-date                  "<xref target='Part2' x:rel='#http.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2625  <!ENTITY messaging                  "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2726  <!ENTITY semantics                  "<xref target='Part2' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     27  <!ENTITY http-date                  "<xref target='Part2' x:rel='#http.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     28  <!ENTITY representation             "<xref target='Part2' x:rel='#representations' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2829  <!ENTITY entity-tags                "<xref target='Part4' x:rel='#header.etag' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2930  <!ENTITY weak-and-strong-validators "<xref target='Part4' x:rel='#weak.and.strong.validators' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    129130<section title="Introduction" anchor="introduction">
    130131<t>
    131    HTTP clients often encounter interrupted data transfers as a result
    132    of canceled requests or dropped connections.  When a client has stored
    133    a partial representation, it is desirable to request the remainder
    134    of that representation in a subsequent request rather than transfer
    135    the entire representation.
    136    There are also a number of Web applications that benefit from being
    137    able to request only a subset of a larger representation, such as a
    138    single page of a very large document or only part of an image to be
    139    rendered by a device with limited local storage.
    140 </t>
    141 <t>
    142    This document defines HTTP/1.1 range requests,
    143    partial responses, and the multipart/byteranges media type.
    144    The protocol for range requests is an &OPTIONAL; feature of HTTP,
    145    designed so resources or recipients that do not implement this feature
    146    can respond as if it is a normal GET request without impacting
    147    interoperability.  Partial responses are indicated by a distinct status
    148    code to not be mistaken for full responses by intermediate caches
    149    that might not implement the feature.
    150 </t>
    151 <t>
    152    Although the HTTP range request mechanism is designed to allow for
     132   Hypertext Transfer Protocol (HTTP) clients often encounter interrupted data
     133   transfers as a result of canceled requests or dropped connections. When a
     134   client has stored a partial representation, it is desirable to request the
     135   remainder of that representation in a subsequent request rather than
     136   transfer the entire representation. Likewise, devices with limited local
     137   storage might benefit from being able to request only a subset of a larger
     138   representation, such as a single page of a very large document, or the
     139   dimensions of an embedded image.
     140</t>
     141<t>
     142   This document defines HTTP/1.1 range requests, partial responses, and the
     143   multipart/byteranges media type, obsoleting those parts previously defined
     144   in <xref target="RFC2616"/>. Range requests are an &OPTIONAL; feature
     145   of HTTP, designed so that recipients not implementing this feature (or not
     146   supporting it for the target resource) can respond as if it is a normal
     147   GET request without impacting interoperability. Partial responses are
     148   indicated by a distinct status code to not be mistaken for full responses
     149   by caches that might not implement the feature.
     150</t>
     151<t>
     152   Although the range request mechanism is designed to allow for
    153153   extensible range types, this specification only defines requests for
    154154   byte ranges.
     
    180180
    181181<section title="Range Units" anchor="range.units">
    182   <x:anchor-alias value="bytes-unit"/>
    183   <x:anchor-alias value="other-range-unit"/>
    184182  <x:anchor-alias value="range-unit"/>
    185183  <x:anchor-alias value="range unit"/>
     
    187185   A representation can be partitioned into subranges according to various
    188186   structural units, depending on the structure inherent in the
    189    representation's media type. Such a <x:dfn>range unit</x:dfn> can be used
    190    in the <x:ref>Range</x:ref> (<xref target="header.range"/>) and
     187   representation's media type. This "<x:dfn>range unit</x:dfn>" is used
     188   in the <x:ref>Accept-Ranges</x:ref> (<xref target="header.accept-ranges"/>)
     189   response header field to advertise support for range requests, the
     190   <x:ref>Range</x:ref> (<xref target="header.range"/>) request header field
     191   to delineate the parts of a representation that are requested, and the
    191192   <x:ref>Content-Range</x:ref> (<xref target="header.content-range"/>)
    192    header fields to delineate the parts of a representation that are
    193    either requested or transferred, respectively.
    194 </t>
    195 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="range-unit"/><iref primary="true" item="Grammar" subitem="bytes-unit"/><iref primary="true" item="Grammar" subitem="other-range-unit"/>
     193   payload header field to describe which part of a representation is being
     194   transferred.
     195</t>
     196<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="range-unit"/><iref item="Grammar" subitem="bytes-unit"/><iref item="Grammar" subitem="other-range-unit"/>
    196197  <x:ref>range-unit</x:ref>       = <x:ref>bytes-unit</x:ref> / <x:ref>other-range-unit</x:ref>
     198</artwork></figure>
     199
     200<section title="Byte Ranges" anchor="byte.ranges">
     201  <x:anchor-alias value="bytes-unit"/>
     202<t>
     203   Since representation data is transferred in payloads as a sequence of
     204   octets, a byte range is a meaningful substructure for any representation
     205   transferable over HTTP (&representation;). We define the "bytes" range
     206   unit for expressing subranges of the data's octet sequence.
     207</t>
     208<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="bytes-unit"/>
    197209  <x:ref>bytes-unit</x:ref>       = "bytes"
    198   <x:ref>other-range-unit</x:ref> = <x:ref>token</x:ref>
    199 </artwork></figure>
    200 
    201 <section title="Byte Ranges" anchor="byte.ranges">
    202 <t>
    203    Since all HTTP representations are transferred as sequences
    204    of bytes, the concept of a byte range is meaningful for any HTTP
    205    representation. (However, not all clients and servers need to support byte-range
    206    operations.)
    207 </t>
    208 <t>
    209    Byte range specifications in HTTP apply to the sequence of bytes in
    210    the representation data (not necessarily the same as the message body).
    211 </t>
     210</artwork></figure>
    212211<t anchor="rule.ranges-specifier">
    213212  <x:anchor-alias value="byte-range-set"/>
     
    310309</artwork></figure>
    311310     </t>
    312      <t>Several legal but not canonical specifications of the second 500
     311     <t>Other valid (but not canonical) specifications of the second 500
    313312        bytes (byte offsets 500-999, inclusive):
    314313<figure><artwork type="example" x:indent-with="   ">
     
    322321
    323322<section title="Other Range Units" anchor="range.units.other">
    324 <t>
    325   The only range unit defined by HTTP/1.1 is "bytes"
    326   (<xref target="byte.ranges"/>). Additional units can be defined as described
    327   in <xref target="range.unit.registry"/>.
    328 </t>
    329 </section>
     323  <x:anchor-alias value="other-range-unit"/>
     324<t>
     325  Range units are intended to be extensible.  New range units ought to be
     326  registered with IANA, as defined in <xref target="range.unit.registry"/>.
     327</t>
     328<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="other-range-unit"/>
     329  <x:ref>other-range-unit</x:ref> = <x:ref>token</x:ref>
     330</artwork></figure>
     331</section>
     332
    330333<section title="Accept-Ranges" anchor="header.accept-ranges">
    331334  <iref primary="true" item="Accept-Ranges header field" x:for-anchor=""/>
     
    825828   <c>bytes</c>
    826829   <c>a range of octets</c>
    827    <c><xref target="range.units"/></c>
     830   <c><xref target="byte.ranges"/></c>
    828831
    829832   <c>none</c>
Note: See TracChangeset for help on using the changeset viewer.