Changeset 1910 for draft-ietf-httpbis/latest

Timestamp:

22/09/12 06:35:14 (8 years ago)

Author:

fielding@…

Message:

(editorial) be more consistent when referring to a "body", preferring the
defined terms for message (body), payload (body), and representation (data).

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (5 diffs)
• p1-messaging.xml (modified) (1 diff)
• p2-semantics.html (modified) (19 diffs)
• p2-semantics.xml (modified) (25 diffs)
• p5-range.html (modified) (8 diffs)
• p5-range.xml (modified) (4 diffs)
• p6-cache.html (modified) (7 diffs)
• p6-cache.xml (modified) (2 diffs)

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

@@ -1882 +1882 @@
          except as noted above to replace an empty path with "/" or "*".
       </p>
-      <p id="rfc.section.5.8.p.3">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="p2-semantics.html#payload" title="Message Payload">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
+      <p id="rfc.section.5.8.p.3">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="p2-semantics.html#payload" title="Message Payload">Section 3.4</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
       </p>
       <p id="rfc.section.5.8.p.4">A non-transforming proxy <em class="bcp14">SHOULD NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the
@@ -1892 +1892 @@
          <li><a href="p2-semantics.html#header.allow" class="smpl">Allow</a> (<a href="p2-semantics.html#header.allow" title="Allow">Section 7.4.1</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
          </li>
-         <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 3.2.4</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
+         <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 3.1.4</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
          </li>
          <li>Content-MD5 (<a href="http://tools.ietf.org/html/rfc2616#section-14.15">Section 14.15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>)
@@ -1908 +1908 @@
       </p>
       <ul>
-         <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 3.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
+         <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 3.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
          </li>
          <li><a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>)
          </li>
-         <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 3.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
+         <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 3.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
          </li>
       </ul>
@@ -3225 +3225 @@
       <p id="rfc.section.D.8.p.2">Partly resolved issues: </p>
       <ul>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/88">http://tools.ietf.org/wg/httpbis/trac/ticket/88</a>&gt;: "205 Bodies" (took out language that implied that there might be methods for which a request body MUST NOT be included)
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/88">http://tools.ietf.org/wg/httpbis/trac/ticket/88</a>&gt;: "205 Bodies" (took out language that implied that there might be methods for which a payload body MUST NOT be included)
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/163">http://tools.ietf.org/wg/httpbis/trac/ticket/163</a>&gt;: "editorial improvements around HTTP-date"
@@ -3638 +3638 @@
                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">4.3</a>, <a href="#rfc.xref.Part2.17">5.1</a>, <a href="#rfc.xref.Part2.18">5.3</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.8</a>, <a href="#rfc.xref.Part2.22">5.8</a>, <a href="#rfc.xref.Part2.23">5.8</a>, <a href="#rfc.xref.Part2.24">5.8</a>, <a href="#rfc.xref.Part2.25">5.8</a>, <a href="#rfc.xref.Part2.26">5.9</a>, <a href="#rfc.xref.Part2.27">6.2.2.1</a>, <a href="#rfc.xref.Part2.28">6.2.2.2</a>, <a href="#rfc.xref.Part2.29">6.3</a>, <a href="#rfc.xref.Part2.30">7.4</a>, <a href="#rfc.xref.Part2.31">8.6</a>, <a href="#rfc.xref.Part2.32">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7</a></li>
-                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.8</a></li>
-                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">5.8</a></li>
-                        <li><em>Section 3.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">5.8</a></li>
-                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">5.8</a></li>
+                        <li><em>Section 3.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">5.8</a></li>
+                        <li><em>Section 3.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">5.8</a></li>
+                        <li><em>Section 3.1.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">5.8</a></li>
+                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.8</a></li>
                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a></li>
                         <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">6.2.2.1</a>, <a href="#rfc.xref.Part2.28">6.2.2.2</a></li>

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

@@ -5413 +5413 @@
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/88"/>:
       "205 Bodies" (took out language that implied that there might be
-      methods for which a request body MUST NOT be included)
+      methods for which a payload body MUST NOT be included)
     </t>
     <t>

draft-ietf-httpbis/latest/p2-semantics.html

@@ -880 +880 @@
       </p>
       <p id="rfc.section.3.p.2">For the purposes of HTTP, a <dfn>representation</dfn> is information that reflects the current or desired state of a given resource, in a format that can be readily communicated
-         via the protocol, consisting of a set of metadata (representation header fields) and a potentially unbounded stream of data
-         (representation body).
+         via the protocol, consisting of a set of metadata (representation header fields) and a potentially unbounded stream of octets
+         (representation data).
       </p>
       <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2>
@@ -941 +941 @@
       </p>
       <div id="rfc.figure.u.4"></div><pre class="text">  Content-Encoding: gzip
-</pre><p id="rfc.section.3.1.2.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding
+</pre><p id="rfc.section.3.1.2.p.5">The content-coding is a characteristic of the representation. Typically, the representation data is stored with this encoding
          and is only decoded before rendering or analogous usage. However, a transforming proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control
          directive is present in the message.
@@ -965 +965 @@
       <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#header.content-language" class="smpl">Content-Language</a> = 1#<a href="#language.tags" class="smpl">language-tag</a>
 </pre><p id="rfc.section.3.1.3.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;8.6</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the
-         user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate
-         field is
+         user's own preferred language. Thus, if the content is intended only for a Danish-literate audience, the appropriate field
+         is
       </p>
       <div id="rfc.figure.u.6"></div><pre class="text">  Content-Language: da
@@ -1051 +1051 @@
       </div>
       <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="representation.data" href="#representation.data">Representation Data</a></h2>
-      <p id="rfc.section.3.3.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred
+      <p id="rfc.section.3.3.p.1">The representation data associated with an HTTP message is either provided as the payload body of the message or referred
          to by the message semantics and the effective request URI. The representation data is in a format and encoding defined by
          the representation metadata header fields.
@@ -1064 +1064 @@
       </p>
       <p id="rfc.section.3.3.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for
-         a given representation, with the result that some clients will examine a response body's content and override the specified
-         type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege
-         escalation"). Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats
-         match multiple media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling
-         such "content sniffing" when it is used.
+         a given representation, with the result that some clients will examine a payload's content and override the specified type.
+         Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege escalation").
+         Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats match multiple
+         media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling such "content
+         sniffing" when it is used.
       </p>
       <p id="rfc.section.3.3.p.6"> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> is used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that
@@ -1077 +1077 @@
       <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="payload" href="#payload">Message Payload</a></h2>
       <p id="rfc.section.3.4.p.1">Some HTTP messages transfer a complete or partial representation as the message "<dfn>payload</dfn>". In some cases, a payload might only contain the associated representation's header fields (e.g., responses to HEAD) or
-         only some part(s) of the representation body (e.g., the <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> status code).
+         only some part(s) of the representation data (e.g., the <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> status code).
       </p>
       <p id="rfc.section.3.4.p.2">The purpose of a payload in a request is defined by the method semantics. In a response, the payload's purpose is defined
@@ -1087 +1087 @@
       </p>
       <p id="rfc.section.3.4.p.4">Likewise, the payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>) contains a representation of the target resource, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.2.1</a>), whereas the same status code in a response to POST might contain either a representation of the processing result or a
-         current representation of the target resource after applying the processing. Some responses only contain the representation's
-         header fields as the payload. Response messages with an error status code usually contain a representation that describes
-         the error and what next steps are suggested for resolving it.
+         current representation of the target resource after applying the processing. Response messages with an error status code usually
+         contain a representation that describes the error and what next steps are suggested for resolving it.
       </p>
       <h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;<a id="payload.header.fields" href="#payload.header.fields">Payload Header Fields</a></h3>
@@ -1376 +1375 @@
          to be completed without transferring data already held by the client.
       </p>
-      <p id="rfc.section.4.3.1.p.5">Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations
-         to reject the request.
+      <p id="rfc.section.4.3.1.p.5">A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some
+         existing implementations to reject the request.
       </p>
       <p id="rfc.section.4.3.1.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
@@ -1386 +1385 @@
       <div id="rfc.iref.h.1"></div>
       <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the
-         representation implied by the request without transferring the representation body. This method is often used for testing
+         representation implied by the request without transferring the representation data. This method is often used for testing
          hypertext links for validity, accessibility, and recent modification.
       </p>
       <p id="rfc.section.4.3.2.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request. It also has potential side effects on previously stored responses to GET; see <a href="p6-cache.html#head.effects" title="Updating Caches with HEAD Responses">Section 5</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
       </p>
-      <p id="rfc.section.4.3.2.p.3">Bodies on HEAD requests have no defined semantics. Note that sending a body on a HEAD request might cause some existing implementations
-         to reject the request.
+      <p id="rfc.section.4.3.2.p.3">A payload within a HEAD request message has no defined semantics; sending a payload body on a HEAD request might cause some
+         existing implementations to reject the request.
       </p>
       <div id="rfc.iref.p.2"></div>
@@ -1489 +1488 @@
       <p id="rfc.section.4.3.5.p.2">A successful response <em class="bcp14">SHOULD</em> be <a href="#status.200" class="smpl">200 (OK)</a> if the response includes a representation describing the status, <a href="#status.202" class="smpl">202 (Accepted)</a> if the action has not yet been enacted, or <a href="#status.204" class="smpl">204 (No Content)</a> if the action has been enacted but the response does not include a representation.
       </p>
-      <p id="rfc.section.4.3.5.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing
-         implementations to reject the request.
+      <p id="rfc.section.4.3.5.p.3">A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause
+         some existing implementations to reject the request.
       </p>
       <p id="rfc.section.4.3.5.p.4">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses
@@ -1520 +1519 @@
 Proxy-Authorization: basic aGVsbG86d29ybGQ=
 
-</pre><p id="rfc.section.4.3.6.p.9">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations
-         to reject the request.
+</pre><p id="rfc.section.4.3.6.p.9">A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause
+         some existing implementations to reject the request.
       </p>
       <p id="rfc.section.4.3.6.p.10">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded
@@ -1542 +1541 @@
       </p>
       <p id="rfc.section.4.3.7.p.2">Responses to the OPTIONS method are not cacheable.</p>
-      <p id="rfc.section.4.3.7.p.3">If the OPTIONS request includes a message body (as indicated by the presence of <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> or <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a>), then the media type <em class="bcp14">MUST</em> be indicated by a <a href="#header.content-type" class="smpl">Content-Type</a> field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS
+      <p id="rfc.section.4.3.7.p.3">If the OPTIONS request includes a payload, then the media type <em class="bcp14">MUST</em> be indicated by a <a href="#header.content-type" class="smpl">Content-Type</a> field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS
          body to make more detailed queries on the server.
       </p>
@@ -1553 +1552 @@
          with that resource.
       </p>
-      <p id="rfc.section.4.3.7.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification,
-         but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> field with a field-value of "0".
+      <p id="rfc.section.4.3.7.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), possibly including extensions not defined by this specification. The response payload, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a payload is not defined by this specification,
+         but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate representation. If no payload body is included, the response <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> field with a field-value of "0".
       </p>
       <p id="rfc.section.4.3.7.p.7">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;5.1.1</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.
@@ -1641 +1640 @@
       <p id="rfc.section.5.1.2.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>
       <h4 id="rfc.section.5.1.2.1"><a href="#rfc.section.5.1.2.1">5.1.2.1</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h4>
-      <p id="rfc.section.5.1.2.1.p.1">The purpose of the <a href="#status.100" class="smpl">100 (Continue)</a> status code (<a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section&nbsp;6.2.1</a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
-         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
-         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
+      <p id="rfc.section.5.1.2.1.p.1">The purpose of the <a href="#status.100" class="smpl">100 (Continue)</a> status code (<a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section&nbsp;6.2.1</a>) is to allow a client that is sending a request message with a payload to determine if the origin server is willing to accept
+         the request (based on the request header fields) before the client sends the payload body. In some cases, it might either
+         be inappropriate or highly inefficient for the client to send the payload body if the server will reject the message without
          looking at the body.
       </p>
       <p id="rfc.section.5.1.2.1.p.2">Requirements for HTTP/1.1 clients: </p>
       <ul>
-         <li>If a client will wait for a <a href="#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation.
-         </li>
-         <li>A client <em class="bcp14">MUST NOT</em> send an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation if it does not intend to send a request body.
+         <li>If a client will wait for a <a href="#status.100" class="smpl">100 (Continue)</a> response before sending the payload body, it <em class="bcp14">MUST</em> send an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation.
+         </li>
+         <li>A client <em class="bcp14">MUST NOT</em> send an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation if it does not intend to send a payload body.
          </li>
       </ul>
       <p id="rfc.section.5.1.2.1.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
          100-continue" without receiving either a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> or a <a href="#status.100" class="smpl">100 (Continue)</a> status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has
-         never seen a <a href="#status.100" class="smpl">100 (Continue)</a> status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
+         never seen a <a href="#status.100" class="smpl">100 (Continue)</a> status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the payload body.
       </p>
       <p id="rfc.section.5.1.2.1.p.4">Requirements for HTTP/1.1 origin servers: </p>
       <ul>
-         <li>Upon receiving a request which includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.
+         <li>Upon receiving a request which includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the payload body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.
          </li>
          <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility
@@ -1666 +1665 @@
             wait for <a href="#status.100" class="smpl">100 (Continue)</a> status code, applies only to HTTP/1.1 requests, and not to requests with any other HTTP-version value.
          </li>
-         <li>An origin server <em class="bcp14">MAY</em> omit a <a href="#status.100" class="smpl">100 (Continue)</a> response if it has already received some or all of the request body for the corresponding request.
-         </li>
-         <li>An origin server that sends a <a href="#status.100" class="smpl">100 (Continue)</a> response <em class="bcp14">MUST</em> ultimately send a final status code, once the request body is received and processed, unless it terminates the transport connection
+         <li>An origin server <em class="bcp14">MAY</em> omit a <a href="#status.100" class="smpl">100 (Continue)</a> response if it has already received some or all of the payload body for the corresponding request.
+         </li>
+         <li>An origin server that sends a <a href="#status.100" class="smpl">100 (Continue)</a> response <em class="bcp14">MUST</em> ultimately send a final status code, once the payload body is received and processed, unless it terminates the transport connection
             prematurely.
          </li>
-         <li>If an origin server receives a request that does not include an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, the request includes a request body, and the server responds with a final
-            status code before reading the entire request body from the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise,
+         <li>If an origin server receives a request that does not include an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, the request includes a payload body, and the server responds with a final
+            status code before reading the entire payload body from the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise,
             the client might not reliably receive the response message. However, this requirement ought not be construed as preventing
             a server from defending itself against denial-of-service attacks, or from badly broken client implementations.
@@ -2603 +2602 @@
       <h3 id="rfc.section.6.5.8"><a href="#rfc.section.6.5.8">6.5.8</a>&nbsp;<a id="status.409" href="#status.409">409 Conflict</a></h3>
       <p id="rfc.section.6.5.8.p.1">The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in
-         situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response
-         body <em class="bcp14">SHOULD</em> include enough information for the user to recognize the source of the conflict. Ideally, the response representation would
+         situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The payload <em class="bcp14">SHOULD</em> include enough information for the user to recognize the source of the conflict. Ideally, the response representation would
          include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
       </p>
@@ -3172 +3170 @@
       </p>
       <h3 id="rfc.section.9.1.2"><a href="#rfc.section.9.1.2">9.1.2</a>&nbsp;<a id="considerations.for.new.methods" href="#considerations.for.new.methods">Considerations for New Methods</a></h3>
-      <p id="rfc.section.9.1.2.p.1">Standardized HTTP methods are generic; that is, they are potentially applicable to any resource, not just one particular media
-         type, kind of resource, or application. As such, it is preferred that new HTTP methods be registered in a document that isn't
-         specific to a single application or data format, since orthogonal technologies deserve orthogonal specification.
-      </p>
-      <p id="rfc.section.9.1.2.p.2">Since HTTP message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is independent of method semantics (aside from responses to HEAD), definitions of new HTTP methods cannot change the parsing
-         algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of new methods
-         can specify that only zero-length bodies are allowed, which would imply that each such messages would be required to contain
-         a Content-Length header field with a value of "0".
-      </p>
-      <p id="rfc.section.9.1.2.p.3">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section&nbsp;4.2.1</a>), idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section&nbsp;4.2.2</a>), cacheable (<a href="#cacheable.methods" title="Cacheable Methods">Section&nbsp;4.2.3</a>), and what semantics are to be associated with the request body if any is present in the request. If a method is cacheable,
+      <p id="rfc.section.9.1.2.p.1">Standardized methods are generic; that is, they are potentially applicable to any resource, not just one particular media
+         type, kind of resource, or application. As such, it is preferred that new methods be registered in a document that isn't specific
+         to a single application or data format, since orthogonal technologies deserve orthogonal specification.
+      </p>
+      <p id="rfc.section.9.1.2.p.2">Since message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the
+         parsing algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of
+         new methods can specify that only a zero-length message body is allowed by requiring a Content-Length header field with a
+         value of "0".
+      </p>
+      <p id="rfc.section.9.1.2.p.3">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section&nbsp;4.2.1</a>), idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section&nbsp;4.2.2</a>), cacheable (<a href="#cacheable.methods" title="Cacheable Methods">Section&nbsp;4.2.3</a>), and what semantics are to be associated with the payload body if any is present in the request. If a method is cacheable,
          the method definition ought to describe how, and under what conditions, a cache can store a response and use it to satisfy
          a subsequent request.
@@ -3272 +3270 @@
          isn't specific to a single application.
       </p>
-      <p id="rfc.section.9.2.2.p.2">New status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Response Status Codes">Section&nbsp;6</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a response body, although they can mandate
-         a zero-length response body.
+      <p id="rfc.section.9.2.2.p.2">New status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Response Status Codes">Section&nbsp;6</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a payload, although they can mandate
+         a zero-length payload body.
       </p>
       <p id="rfc.section.9.2.2.p.3">A definition for a new status code ought to explain the request conditions that produce a response containing that status
@@ -4487 +4485 @@
       <p id="rfc.section.F.8.p.1">Closed issues: </p>
       <ul>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/98">http://tools.ietf.org/wg/httpbis/trac/ticket/98</a>&gt;: "OPTIONS request bodies"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/98">http://tools.ietf.org/wg/httpbis/trac/ticket/98</a>&gt;: "OPTIONS payload bodies"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/119">http://tools.ietf.org/wg/httpbis/trac/ticket/119</a>&gt;: "Description of CONNECT should refer to RFC2817"

draft-ietf-httpbis/latest/p2-semantics.xml

@@ -302 +302 @@
    that can be readily communicated via the protocol, consisting of a set of
    metadata (representation header fields) and a potentially unbounded stream
-   of data (representation body).
+   of octets (representation data).
 </t>
 
@@ -371 +371 @@
 <t>
    The content-coding is a characteristic of the representation.
-   Typically, the representation body is stored with this
+   Typically, the representation data is stored with this
    encoding and is only decoded before rendering or analogous usage.
    However, a transforming proxy &MAY; modify the content-coding if the
@@ -422 +422 @@
    Content-Language is to allow a user to identify and differentiate
    representations according to the user's own preferred language. Thus, if the
-   body content is intended only for a Danish-literate audience, the
+   content is intended only for a Danish-literate audience, the
    appropriate field is
 </t>
@@ -569 +569 @@
   <x:anchor-alias value="representation-data"/>
 <t>
-   The representation body associated with an HTTP message is
+   The representation data associated with an HTTP message is
    either provided as the payload body of the message or
    referred to by the message semantics and the effective request
@@ -599 +599 @@
    In practice, resource owners do not always properly configure their origin
    server to provide the correct Content-Type for a given representation,
-   with the result that some clients will examine a response body's content
+   with the result that some clients will examine a payload's content
    and override the specified type.
    Clients that do so risk drawing incorrect conclusions, which might expose
@@ -623 +623 @@
    message "<x:dfn>payload</x:dfn>".  In some cases, a payload might only
    contain the associated representation's header fields (e.g., responses to
-   HEAD) or only some part(s) of the representation body
+   HEAD) or only some part(s) of the representation data
    (e.g., the <x:ref>206 (Partial Content)</x:ref> status code).
 </t>
@@ -646 +646 @@
    to POST might contain either a representation of the processing result or
    a current representation of the target resource after applying the
-   processing. Some responses only contain the representation's header fields
-   as the payload. Response messages with an error status code usually contain
+   processing. Response messages with an error status code usually contain
    a representation that describes the error and what next steps are suggested
    for resolving it.
@@ -1112 +1111 @@
 </t>
 <t>
-   Bodies on GET requests have no defined semantics. Note that sending a body
-   on a GET request might cause some existing implementations to reject the
-   request.
+   A payload within a GET request message has no defined semantics;
+   sending a payload body on a GET request might cause some existing
+   implementations to reject the request.
 </t>
 <t>
@@ -1137 +1136 @@
    to the information sent in response to a GET request. This method can
    be used for obtaining metadata about the representation implied by the
-   request without transferring the representation body. This method is
+   request without transferring the representation data. This method is
    often used for testing hypertext links for validity, accessibility,
    and recent modification.
@@ -1147 +1146 @@
 </t>
 <t>
-   Bodies on HEAD requests have no defined semantics. Note that sending a body
-   on a HEAD request might cause some existing implementations to reject the
-   request.
+   A payload within a HEAD request message has no defined semantics;
+   sending a payload body on a HEAD request might cause some existing
+   implementations to reject the request.
 </t>
 </section>
@@ -1358 +1357 @@
 </t>
 <t>
-   Bodies on DELETE requests have no defined semantics. Note that sending a body
-   on a DELETE request might cause some existing implementations to reject the
-   request.
+   A payload within a DELETE request message has no defined semantics;
+   sending a payload body on a DELETE request might cause some existing
+   implementations to reject the request.
 </t>
 <t>
@@ -1417 +1416 @@
 </artwork></figure>
 <t>
-   A message body on a CONNECT request has no defined semantics. Sending a
-   body on a CONNECT request might cause existing implementations to reject
-   the request.
+   A payload within a CONNECT request message has no defined semantics;
+   sending a payload body on a CONNECT request might cause some existing
+   implementations to reject the request.
 </t>
 <t>
@@ -1469 +1468 @@
 </t>
 <t>
-   If the OPTIONS request includes a message body (as indicated by the
-   presence of <x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref>),
+   If the OPTIONS request includes a payload,
    then the media type &MUST; be indicated by a <x:ref>Content-Type</x:ref>
    field. Although this specification does not define any use for such a body,
@@ -1495 +1493 @@
    indicate optional features implemented by the server and applicable to that
    resource (e.g., <x:ref>Allow</x:ref>), possibly including extensions not
-   defined by this specification. The response body, if any, &SHOULD; also
+   defined by this specification. The response payload, if any, &SHOULD; also
    include information about the communication options. The format for such a
-   body is not defined by this specification, but might be defined by
+   payload is not defined by this specification, but might be defined by
    future extensions to HTTP. Content negotiation &MAY; be used to select
-   the appropriate response format. If no response body is included, the
+   the appropriate representation. If no payload body is included, the
    response &MUST; include a <x:ref>Content-Length</x:ref> field with a
    field-value of "0".
@@ -1660 +1658 @@
    The purpose of the <x:ref>100 (Continue)</x:ref> status code
    (<xref target='status.100'/>)
-   is to allow a client that is sending a request message with a request body
+   is to allow a client that is sending a request message with a payload
    to determine if the origin server is willing to accept the request
-   (based on the request header fields) before the client sends the request
+   (based on the request header fields) before the client sends the payload
    body. In some cases, it might either be inappropriate or highly
-   inefficient for the client to send the body if the server will reject
-   the message without looking at the body.
+   inefficient for the client to send the payload body if the server will
+   reject the message without looking at the body.
 </t>
 <t>
@@ -1672 +1670 @@
     <t>
         If a client will wait for a <x:ref>100 (Continue)</x:ref> response before
-        sending the request body, it &MUST; send an <x:ref>Expect</x:ref> header
+        sending the payload body, it &MUST; send an <x:ref>Expect</x:ref> header
         field with the "100-continue" expectation.
     </t>
     <t>
         A client &MUST-NOT; send an <x:ref>Expect</x:ref> header field with
-        the "100-continue" expectation if it does not intend to send a request
+        the "100-continue" expectation if it does not intend to send a payload
         body.
     </t>
@@ -1689 +1687 @@
    header field to an origin server (possibly via a proxy) from which it
    has never seen a <x:ref>100 (Continue)</x:ref> status code, the client &SHOULD-NOT;  
-   wait for an indefinite period before sending the request body.
+   wait for an indefinite period before sending the payload body.
 </t>
 <t>
@@ -1698 +1696 @@
         either respond with <x:ref>100 (Continue)</x:ref> status code and continue to read
         from the input stream, or respond with a final status code. The
-        origin server &MUST-NOT; wait for the request body before sending
+        origin server &MUST-NOT; wait for the payload body before sending
         the <x:ref>100 (Continue)</x:ref> response. If it responds with a final status
         code, it &MAY; close the transport connection or it &MAY; continue
@@ -1719 +1717 @@
     </t>
     <t> An origin server &MAY; omit a <x:ref>100 (Continue)</x:ref> response if it has
-        already received some or all of the request body for the
+        already received some or all of the payload body for the
         corresponding request.
     </t>
     <t> An origin server that sends a <x:ref>100 (Continue)</x:ref> response &MUST;
-        ultimately send a final status code, once the request body is
+        ultimately send a final status code, once the payload body is
         received and processed, unless it terminates the transport
         connection prematurely.
@@ -1729 +1727 @@
     <t> If an origin server receives a request that does not include an
         <x:ref>Expect</x:ref> header field with the "100-continue" expectation,
-        the request includes a request body, and the server responds
-        with a final status code before reading the entire request body
+        the request includes a payload body, and the server responds
+        with a final status code before reading the entire payload body
         from the transport connection, then the server &SHOULD-NOT;  close
         the transport connection until it has read the entire request,
@@ -3021 +3019 @@
    state of the resource. This code is only allowed in situations where
    it is expected that the user might be able to resolve the conflict
-   and resubmit the request. The response body &SHOULD; include enough
+   and resubmit the request. The payload &SHOULD; include enough
    information for the user to recognize the source of the conflict.
    Ideally, the response representation would include enough information for the
@@ -4026 +4024 @@
 <section title="Considerations for New Methods" anchor="considerations.for.new.methods">
 <t>
-   Standardized HTTP methods are generic; that is, they are potentially
+   Standardized methods are generic; that is, they are potentially
    applicable to any resource, not just one particular media type, kind of
-   resource, or application. As such, it is preferred that new HTTP methods
+   resource, or application. As such, it is preferred that new methods
    be registered in a document that isn't specific to a single application or
    data format, since orthogonal technologies deserve orthogonal specification.
 </t>
 <t>
-   Since HTTP message parsing (&message-body;) is independent of method
-   semantics (aside from responses to HEAD), definitions of new HTTP methods
+   Since message parsing (&message-body;) needs to be independent of method
+   semantics (aside from responses to HEAD), definitions of new methods
    cannot change the parsing algorithm or prohibit the presence of a message
    body on either the request or the response message.
-   Definitions of new methods can specify that only zero-length bodies are
-   allowed, which would imply that each such messages would be required to
-   contain a Content-Length header field with a value of "0".
+   Definitions of new methods can specify that only a zero-length message body
+   is allowed by requiring a Content-Length header field with a value of "0".
 </t>
 <t>
@@ -4045 +4042 @@
    target="safe.methods"/>), idempotent (<xref target="idempotent.methods"/>),
    cacheable (<xref target="cacheable.methods"/>), and what
-   semantics are to be associated with the request body if any is present
+   semantics are to be associated with the payload body if any is present
    in the request.  If a method is cacheable, the method definition ought
    to describe how, and under what conditions, a cache can store a response
@@ -4148 +4145 @@
    New status codes are required to fall under one of the categories
    defined in <xref target="status.codes"/>. To allow existing parsers to
-   properly handle them, new status codes cannot disallow a response body,
-   although they can mandate a zero-length response body.
+   properly handle them, new status codes cannot disallow a payload,
+   although they can mandate a zero-length payload body.
 </t>
 <t>
@@ -6266 +6263 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/98"/>:
-      "OPTIONS request bodies"
+      "OPTIONS payload bodies"
     </t>
     <t>

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires March 22, 2013"; 
+       content: "Expires March 25, 2013"; 
   } 
   @bottom-right {
@@ -493 +493 @@
       <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="2012-09-18">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-09-21">
       <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.">
@@ -519 +519 @@
             </tr>
             <tr>
-               <td class="left">Expires: March 22, 2013</td>
+               <td class="left">Expires: March 25, 2013</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -528 +528 @@
             <tr>
                <td class="left"></td>
-               <td class="right">September 18, 2012</td>
+               <td class="right">September 21, 2012</td>
             </tr>
          </tbody>
@@ -553 +553 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on March 22, 2013.</p>
+      <p>This Internet-Draft will expire on March 25, 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>
@@ -855 +855 @@
          representation. (However, not all clients and servers need to support byte-range operations.)
       </p>
-      <p id="rfc.section.5.4.1.p.2">Byte range specifications in HTTP apply to the sequence of bytes in the representation body (not necessarily the same as the
+      <p id="rfc.section.5.4.1.p.2">Byte range specifications in HTTP apply to the sequence of bytes in the representation data (not necessarily the same as the
          message body).
       </p>
@@ -875 +875 @@
       </p>
       <p id="rfc.section.5.4.1.p.7">If the last-byte-pos value is absent, or if the value is greater than or equal to the current length of the representation
-         body, last-byte-pos is taken to be equal to one less than the current length of the representation in bytes.
+         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.5.4.1.p.8">By its choice of last-byte-pos, a client can limit the number of bytes retrieved without knowing the size of the representation.</p>
       <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></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.5.4.1.p.10">A suffix-byte-range-spec is used to specify the suffix of the representation body, of a length given by the suffix-length
+</pre><p id="rfc.section.5.4.1.p.10">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.
@@ -912 +912 @@
       <h3 id="rfc.section.5.4.2"><a href="#rfc.section.5.4.2">5.4.2</a>&nbsp;<a id="range.retrieval.requests" href="#range.retrieval.requests">Range Retrieval Requests</a></h3>
       <p id="rfc.section.5.4.2.p.1">The "Range" header field defines the GET method (conditional or not) to request one or more sub-ranges of the response representation
-         body, instead of the entire representation body.
+         data, instead of the entire representation data.
       </p>
       <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.19"></span>  <a href="#range.retrieval.requests" class="smpl">Range</a> = <a href="#rule.ranges-specifier" class="smpl">byte-ranges-specifier</a> / <a href="#range.retrieval.requests" class="smpl">other-ranges-specifier</a>

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

@@ -627 +627 @@
 <t>
    Byte range specifications in HTTP apply to the sequence of bytes in
-   the representation body (not necessarily the same as the message body).
+   the representation data (not necessarily the same as the message body).
 </t>
 <t anchor="rule.ranges-specifier">
@@ -663 +663 @@
 <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 body, last-byte-pos is
+   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.
@@ -677 +677 @@
 <t>
    A suffix-byte-range-spec is used to specify the suffix of the
-   representation body, of a length given by the suffix-length value. (That is,
+   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
@@ -746 +746 @@
 <t>
    The "Range" header field defines the GET method (conditional or
-   not) to request one or more sub-ranges of the response representation body, instead
-   of the entire representation body.
+   not) to request one or more sub-ranges of the response representation data, instead
+   of the entire representation data.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Range"/>

draft-ietf-httpbis/latest/p6-cache.html

@@ -452 +452 @@
   } 
   @bottom-center {
-       content: "Expires March 22, 2013"; 
+       content: "Expires March 25, 2013"; 
   } 
   @bottom-right {
@@ -499 +499 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-09-18">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-09-21">
       <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 requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
@@ -525 +525 @@
             </tr>
             <tr>
-               <td class="left">Expires: March 22, 2013</td>
+               <td class="left">Expires: March 25, 2013</td>
                <td class="right">M. Nottingham, Editor</td>
             </tr>
@@ -538 +538 @@
             <tr>
                <td class="left"></td>
-               <td class="right">September 18, 2012</td>
+               <td class="right">September 21, 2012</td>
             </tr>
          </tbody>
@@ -564 +564 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on March 22, 2013.</p>
+      <p>This Internet-Draft will expire on March 25, 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>
@@ -772 +772 @@
       </p>
       <ul class="empty">
-         <li>A validator that is defined by the origin server such that its current value will change if the representation body changes;
+         <li>A validator that is defined by the origin server such that its current value will change if the representation data changes;
             i.e., an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value that is 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>.
          </li>
@@ -1066 +1066 @@
          <li>A <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Responses with 304 Not Modified">Section&nbsp;4.2.1</a>.
          </li>
-         <li>A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional
-            request is suitable. Instead, the cache can use the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response(s).
+         <li>A full response (i.e., one with a payload body) indicates that none of the stored responses nominated in the conditional request
+            is suitable. Instead, the cache can use the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response(s).
          </li>
          <li>However, if a cache receives a <a href="p2-semantics.html#status.5xx" class="smpl">5xx (Server Error)</a> response while attempting to validate a response, it can either forward this response to the requesting client, or act as

draft-ietf-httpbis/latest/p6-cache.xml

@@ -291 +291 @@
    <list>
       <t>A validator that is defined by the origin server such that its
-         current value will change if the representation body changes; i.e.,
+         current value will change if the representation data changes; i.e.,
          an entity-tag that is not marked as weak (&entity-tags;) or,
          if no entity-tag is provided, a <x:ref>Last-Modified</x:ref> value
@@ -878 +878 @@
       </t>
       <t>
-         A full response (i.e., one with a response body) indicates that none
+         A full response (i.e., one with a payload body) indicates that none
          of the stored responses nominated in the conditional request is
          suitable. Instead, the cache can use the full response to