Changeset 1540 for draft-ietf-httpbis/latest

Timestamp:

20/02/12 09:10:22 (9 years ago)

Author:

fielding@…

Message:

Consolidate and clean the description and requirements for Transfer-Encoding

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (13 diffs)
• p1-messaging.xml (modified) (10 diffs)

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

@@ -460 +460 @@
   } 
   @bottom-center {
-       content: "Expires August 22, 2012"; 
+       content: "Expires August 23, 2012"; 
   } 
   @bottom-right {
@@ -510 +510 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-02-19">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-02-20">
       <meta name="dct.replaces" content="urn:ietf:rfc:2145">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
@@ -542 +542 @@
             </tr>
             <tr>
-               <td class="left">Expires: August 22, 2012</td>
+               <td class="left">Expires: August 23, 2012</td>
                <td class="right">HP</td>
             </tr>
@@ -595 +595 @@
             <tr>
                <td class="left"></td>
-               <td class="right">February 19, 2012</td>
+               <td class="right">February 20, 2012</td>
             </tr>
          </tbody>
@@ -628 +628 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on August 22, 2012.</p>
+      <p>This Internet-Draft will expire on August 23, 2012.</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>
@@ -702 +702 @@
                <li>4.2&nbsp;&nbsp;&nbsp;<a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li>
                <li>4.3&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li>
-               <li>4.4&nbsp;&nbsp;&nbsp;<a href="#associating.request.response">Associating Response to Request</a></li>
+               <li>4.4&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li>
             </ul>
          </li>
@@ -1452 +1452 @@
       </p>
       <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="message.body" href="#message.body">Message Body</a></h2>
-      <p id="rfc.section.3.3.p.1">The message-body (if any) of an HTTP message is used to carry the payload body associated with the request or response.</p>
+      <p id="rfc.section.3.3.p.1">The message body (if any) of an HTTP message is used to carry the payload body of that request or response. The message body
+         is identical to the payload body unless a transfer coding has been applied, as described in <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;3.3.1</a>.
+      </p>
       <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.51"></span>  <a href="#message.body" class="smpl">message-body</a> = *OCTET
-</pre><p id="rfc.section.3.3.p.3">The message-body differs from the payload body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding
-         header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;3.3.1</a>).
-      </p>
-      <p id="rfc.section.3.3.p.4">The rules for when a message-body is allowed in a message differ for requests and responses.</p>
-      <p id="rfc.section.3.3.p.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field
-         in the request's header fields, even if the request method does not define any use for a message-body. This allows the request
-         message framing algorithm to be independent of method semantics.
-      </p>
-      <p id="rfc.section.3.3.p.6">For response messages, whether or not a message-body is included with a message is dependent on both the request method and
-         the response status code (<a href="#status.code" title="Status Code">Section&nbsp;3.1.2.1</a>). Responses to the HEAD request method never include a message-body because the associated response header fields (e.g.,
+</pre><p id="rfc.section.3.3.p.3">The rules for when a message body is allowed in a message differ for requests and responses.</p>
+      <p id="rfc.section.3.3.p.4">The presence of a message body in a request is signaled by a a Content-Length or Transfer-Encoding header field. Request message
+         framing is independent of method semantics, even if the method does not define any use for a message body.
+      </p>
+      <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response
+         status code (<a href="#status.code" title="Status Code">Section&nbsp;3.1.2.1</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g.,
          Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET.
-         All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length.
+         All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length.
       </p>
       <div id="rfc.iref.t.4"></div>
       <div id="rfc.iref.h.6"></div>
       <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h3>
-      <p id="rfc.section.3.3.1.p.1">The "Transfer-Encoding" header field indicates what transfer-codings (if any) have been applied to the message body. It differs
-         from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings
-         are not.
+      <p id="rfc.section.3.3.1.p.1">When one or more transfer encodings are applied to a payload body in order to form the message-body, a Transfer-Encoding header
+         field <em class="bcp14">MUST</em> be sent in the message and <em class="bcp14">MUST</em> contain the list of corresponding transfer-coding names in the same order that they were applied. Transfer encodings are defined
+         in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>.
       </p>
       <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.52"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
-</pre><p id="rfc.section.3.3.1.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>. An example is:
-      </p>
+</pre><p id="rfc.section.3.3.1.p.3">Transfer-Encoding is analogous to the Content-Transfer-Encoding field of MIME, which was designed to enable safe transport
+         of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP's case, Transfer-Encoding is
+         primarily intended to accurately delimit a dynamically generated payload and to distinguish payload encodings that are only
+         applied for transport efficiency or security from those that are characteristics of the target resource.
+      </p>
+      <p id="rfc.section.3.3.1.p.4">The "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1</a>) <em class="bcp14">MUST</em> be implemented by all HTTP/1.1 recipients because it plays a crucial role in delimiting messages when the payload body size
+         is not known in advance. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message body and <em class="bcp14">MUST NOT</em> be applied more than once in a message-body. If any transfer-coding is applied to a request payload body, the final transfer-coding
+         applied <em class="bcp14">MUST</em> be "chunked". If any transfer-coding is applied to a response payload body, then either the final transfer-coding applied <em class="bcp14">MUST</em> be "chunked" or the message <em class="bcp14">MUST</em> be terminated by closing the connection.
+      </p>
+      <p id="rfc.section.3.3.1.p.5">For example,</p>
       <div id="rfc.figure.u.35"></div><pre class="text">  Transfer-Encoding: chunked
-</pre><p id="rfc.section.3.3.1.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
-      </p>
-      <p id="rfc.section.3.3.1.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header field.</p>
-      <p id="rfc.section.3.3.1.p.7">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message-body length.
-      </p>
-      <p id="rfc.section.3.3.1.p.8">When one or more transfer-codings are applied to a payload in order to form the message-body, the Transfer-Encoding header
-         field <em class="bcp14">MUST</em> contain the list of transfer-codings applied. Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain under the constraints found in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>.
+</pre><p id="rfc.section.3.3.1.p.7">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message-body length.
+      </p>
+      <p id="rfc.section.3.3.1.p.8">Unlike Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
+      </p>
+      <p id="rfc.section.3.3.1.p.9">Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will
+         not understand how to process a transfer-encoded payload. A client <em class="bcp14">MUST NOT</em> send a request containing Transfer-Encoding unless it knows the server will handle HTTP/1.1 (or later) requests; such knowledge
+         might be in the form of specific user configuration or by remembering the version of a prior received response. A server <em class="bcp14">MUST NOT</em> send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later).
+      </p>
+      <p id="rfc.section.3.3.1.p.10">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection.
       </p>
       <div id="rfc.iref.c.6"></div>
@@ -1511 +1519 @@
       </p>
       <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;<a id="message.body.length" href="#message.body.length">Message Body Length</a></h3>
-      <p id="rfc.section.3.3.3.p.1">The length of the message-body is determined by one of the following (in order of precedence):</p>
+      <p id="rfc.section.3.3.3.p.1">The length of a message-body is determined by one of the following (in order of precedence):</p>
       <p id="rfc.section.3.3.3.p.2"> </p>
       <ol>
@@ -1520 +1528 @@
          </li>
          <li>
-            <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding
+            <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding
                indicates the data is complete.
             </p>
@@ -1724 +1732 @@
       <p id="rfc.section.4.3.p.9">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section&nbsp;2.7.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/".
       </p>
-      <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="associating.request.response" href="#associating.request.response">Associating Response to Request</a></h2>
+      <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>
       <p id="rfc.section.4.4.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
          messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
@@ -1750 +1758 @@
   <a href="#rule.parameter" class="smpl">value</a>                   = <a href="#rule.token.separators" class="smpl">word</a>
 </pre><p id="rfc.section.5.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;5.4</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;3.3.1</a>).
-      </p>
-      <p id="rfc.section.5.p.6">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport
-         of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic
-         of message-bodies is the difficulty in determining the exact message body length (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>), or the desire to encrypt data over a shared transport.
-      </p>
-      <p id="rfc.section.5.p.7">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.
       </p>
       <div id="rfc.iref.c.7"></div>
@@ -1825 +1827 @@
       </p>
       <p id="rfc.section.5.1.p.10">Use of chunk-ext extensions by senders is deprecated; they <em class="bcp14">SHOULD NOT</em> be sent and definition of new chunk-extensions is discouraged.
-      </p>
-      <p id="rfc.section.5.1.p.11">Since "chunked" is the only transfer-coding required to be understood by HTTP/1.1 recipients, it plays a crucial role in delimiting
-         messages on a persistent connection. Whenever a transfer-coding is applied to a payload body in a request, the final transfer-coding
-         applied <em class="bcp14">MUST</em> be "chunked". If a transfer-coding is applied to a response payload body, then either the final transfer-coding applied <em class="bcp14">MUST</em> be "chunked" or the message <em class="bcp14">MUST</em> be terminated by closing the connection. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once in a message-body.
       </p>
       <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="compression.codings" href="#compression.codings">Compression Codings</a></h2>
@@ -3848 +3846 @@
                   <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">5.2.2</a>, <a href="#rfc.xref.RFC1951.2">9.4</a>, <a href="#RFC1951"><b>12.1</b></a></li>
                   <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">5.2.3</a>, <a href="#rfc.xref.RFC1952.2">9.4</a>, <a href="#RFC1952"><b>12.1</b></a></li>
-                  <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">5</a>, <a href="#RFC2045"><b>12.2</b></a><ul>
-                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.2">5</a></li>
+                  <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">3.3.1</a>, <a href="#RFC2045"><b>12.2</b></a><ul>
+                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.2">3.3.1</a></li>
                      </ul>
                   </li>

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

@@ -1550 +1550 @@
   <x:anchor-alias value="message-body"/>
 <t>
-   The message-body (if any) of an HTTP message is used to carry the
-   payload body associated with the request or response.
+   The message body (if any) of an HTTP message is used to carry the
+   payload body of that request or response.  The message body is
+   identical to the payload body unless a transfer coding has been
+   applied, as described in <xref target="header.transfer-encoding"/>.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="message-body"/>
@@ -1557 +1559 @@
 </artwork></figure>
 <t>
-   The message-body differs from the payload body only when a transfer-coding
-   has been applied, as indicated by the Transfer-Encoding header field
-   (<xref target="header.transfer-encoding"/>).
-</t>
-<t>
-   The rules for when a message-body is allowed in a message differ for
+   The rules for when a message body is allowed in a message differ for
    requests and responses.
 </t>
 <t>
-   The presence of a message-body in a request is signaled by the
-   inclusion of a Content-Length or Transfer-Encoding header field in
-   the request's header fields, even if the request method does not
-   define any use for a message-body.  This allows the request
-   message framing algorithm to be independent of method semantics.
-</t>
-<t>
-   For response messages, whether or not a message-body is included with
-   a message is dependent on both the request method and the response
+   The presence of a message body in a request is signaled by a
+   a Content-Length or Transfer-Encoding header field.
+   Request message framing is independent of method semantics,
+   even if the method does not define any use for a message body.
+</t>
+<t>
+   The presence of a message body in a response depends on both
+   the request method to which it is responding and the response
    status code (<xref target="status.code"/>).
-   Responses to the HEAD request method never include a message-body
+   Responses to the HEAD request method never include a message body
    because the associated response header fields (e.g., Transfer-Encoding,
    Content-Length, etc.) only indicate what their values would have been
-   if the request method had been GET.  All 1xx (Informational), 204 (No Content),
-   and 304 (Not Modified) responses &MUST-NOT; include a message-body.
+   if the request method had been GET.
+   All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
+   responses &MUST-NOT; include a message body.
    All other responses do include a message-body, although the body
    &MAY; be of zero length.
@@ -1590 +1587 @@
   <x:anchor-alias value="Transfer-Encoding"/>
 <t>
-   The "Transfer-Encoding" header field indicates what transfer-codings
-   (if any) have been applied to the message body. It differs from 
-   Content-Encoding (&content-codings;) in that transfer-codings are a property
-   of the message (and therefore are removed by intermediaries), whereas
-   content-codings are not.
+   When one or more transfer encodings are applied to a payload body in order
+   to form the message-body, a Transfer-Encoding header field &MUST; be sent
+   in the message and &MUST; contain the list of corresponding
+   transfer-coding names in the same order that they were applied.
+   Transfer encodings are defined in <xref target="transfer.codings"/>.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/>
@@ -1600 +1597 @@
 </artwork></figure>
 <t>
-   Transfer-codings are defined in <xref target="transfer.codings"/>. An example is:
+   Transfer-Encoding is analogous to the Content-Transfer-Encoding field of
+   MIME, which was designed to enable safe transport of binary data over a
+   7-bit transport service (<xref target="RFC2045" x:fmt="," x:sec="6"/>).
+   However, safe transport has a different focus for an 8bit-clean transfer
+   protocol. In HTTP's case, Transfer-Encoding is primarily intended to
+   accurately delimit a dynamically generated payload and to distinguish
+   payload encodings that are only applied for transport efficiency or
+   security from those that are characteristics of the target resource.
+</t>
+<t>
+   The "chunked" transfer-coding (<xref target="chunked.encoding"/>)
+   &MUST; be implemented by all HTTP/1.1 recipients because it plays a
+   crucial role in delimiting messages when the payload body size is not
+   known in advance.
+   When the "chunked" transfer-coding is used, it &MUST; be the last
+   transfer-coding applied to form the message body and &MUST-NOT;
+   be applied more than once in a message-body.
+   If any transfer-coding is applied to a request payload body,
+   the final transfer-coding applied &MUST; be "chunked".
+   If any transfer-coding is applied to a response payload body, then either
+   the final transfer-coding applied &MUST; be "chunked" or
+   the message &MUST; be terminated by closing the connection.
+</t>
+<t>
+   For example,
 </t>
 <figure><artwork type="example">
@@ -1606 +1627 @@
 </artwork></figure>
 <t>
-   If multiple encodings have been applied to a representation, the transfer-codings
-   &MUST; be listed in the order in which they were applied.
+   If more than one Transfer-Encoding header field is present in a message,
+   the multiple field-values &MUST; be combined into one field-value,
+   according to the algorithm defined in <xref target="header.fields"/>,
+   before determining the message-body length.
+</t>
+<t>
+   Unlike Content-Encoding (&content-codings;), Transfer-Encoding is a
+   property of the message, not of the payload, and thus &MAY; be added or
+   removed by any implementation along the request/response chain.
    Additional information about the encoding parameters &MAY; be provided
    by other header fields not defined by this specification.
 </t>
 <t>
-   Many older HTTP/1.0 applications do not understand the Transfer-Encoding
-   header field.
-</t>
-<t>
-   If more than one
-   Transfer-Encoding header field is present in a message, the multiple
-   field-values &MUST; be combined into one field-value, according to the
-   algorithm defined in <xref target="header.fields"/>, before determining
-   the message-body length.
-</t>
-<t>
-   When one or more transfer-codings are applied to a payload in order to
-   form the message-body, the Transfer-Encoding header field &MUST; contain
-   the list of transfer-codings applied. Transfer-Encoding is a property of
-   the message, not of the payload, and thus &MAY; be added or removed by
-   any implementation along the request/response chain under the constraints
-   found in <xref target="transfer.codings"/>.
+   Transfer-Encoding was added in HTTP/1.1.  It is generally assumed that
+   implementations advertising only HTTP/1.0 support will not understand
+   how to process a transfer-encoded payload.
+   A client &MUST-NOT; send a request containing Transfer-Encoding unless it
+   knows the server will handle HTTP/1.1 (or later) requests; such knowledge
+   might be in the form of specific user configuration or by remembering the
+   version of a prior received response.
+   A server &MUST-NOT; send a response containing Transfer-Encoding unless
+   the corresponding request indicates HTTP/1.1 (or later).
+</t>
+<t>
+   A server that receives a request message with a transfer-coding it does
+   not understand &SHOULD; respond with 501 (Not Implemented) and then
+   close the connection.
 </t>
 </section>
@@ -1688 +1713 @@
 <section title="Message Body Length" anchor="message.body.length">
 <t>
-   The length of the message-body is determined by one of the following
+   The length of a message-body is determined by one of the following
    (in order of precedence):
 </t>
@@ -1701 +1726 @@
     <x:lt><t>
      If a Transfer-Encoding header field is present
-     and the "chunked" transfer-coding (<xref target="transfer.codings"/>)
+     and the "chunked" transfer-coding (<xref target="chunked.encoding"/>)
      is the final encoding, the message-body length is determined by reading
      and decoding the chunked data until the transfer-coding indicates the
@@ -2111 +2136 @@
 </section>
 
-<section title="Associating Response to Request" anchor="associating.request.response">
+<section title="Associating a Response to a Request" anchor="associating.response.to.request">
 <t>
    HTTP does not include a request identifier for associating a given
@@ -2165 +2190 @@
    transfer-coding values in the TE header field (<xref target="header.te"/>) and in
    the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>).
-</t>
-<t>
-   Transfer-codings are analogous to the Content-Transfer-Encoding values of
-   MIME, which were designed to enable safe transport of binary data over a
-   7-bit transport service (<xref target="RFC2045" x:fmt="," x:sec="6"/>).
-   However, safe transport
-   has a different focus for an 8bit-clean transfer protocol. In HTTP,
-   the only unsafe characteristic of message-bodies is the difficulty in
-   determining the exact message body length (<xref target="message.body"/>),
-   or the desire to encrypt data over a shared transport.
-</t>
-<t>
-   A server that receives a request message with a transfer-coding it does
-   not understand &SHOULD; respond with 501 (Not Implemented) and then
-   close the connection. A server &MUST-NOT; send transfer-codings to an HTTP/1.0
-   client.
 </t>
 
@@ -2291 +2300 @@
    Use of chunk-ext extensions by senders is deprecated; they &SHOULD-NOT; be
    sent and definition of new chunk-extensions is discouraged. 
-</t>
-<t>
-   Since "chunked" is the only transfer-coding required to be understood
-   by HTTP/1.1 recipients, it plays a crucial role in delimiting messages
-   on a persistent connection.  Whenever a transfer-coding is applied to
-   a payload body in a request, the final transfer-coding applied &MUST;
-   be "chunked".  If a transfer-coding is applied to a response payload
-   body, then either the final transfer-coding applied &MUST; be "chunked"
-   or the message &MUST; be terminated by closing the connection. When the
-   "chunked" transfer-coding is used, it &MUST; be the last transfer-coding
-   applied to form the message-body. The "chunked" transfer-coding &MUST-NOT;
-   be applied more than once in a message-body.
 </t>
 </section>