Merge pull request #872 from kaduk/messaging-nits

Editorial suggestions from Benjamin Kaduk's IESG review (-messaging)

draft-ietf-httpbis-messaging-latest.xml

@@ -623,7 +623,8 @@ GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
    empty Host header field will be sent in this case.
 </t>
 <t>
-   To allow for transition to the absolute-form for all requests in some
+   To allow for the possibility of a transition
+   to the absolute-form for all requests in some
    future version of HTTP, a server &MUST; accept the absolute-form
    in requests, even though HTTP/1.1 clients will only send them in requests
    to proxies.
@@ -652,6 +653,7 @@ GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
 <sourcecode type="http-message">
 CONNECT www.example.com:80 HTTP/1.1
 Host: www.example.com
+
 </sourcecode>
 </section>
 
@@ -1151,14 +1153,17 @@ Transfer-Encoding: gzip, chunked
    framing is invalid and the recipient &MUST; treat it as an unrecoverable
    error, unless the field value can be successfully parsed as a
    comma-separated list (<xref target="abnf.extension"/>), all values in the
-   list are valid, and all values in the list are the same.
-   If this is a request message, the server &MUST; respond with
+   list are valid, and all values in the list are the same (in which case the
+   message is processed with that single value used as the Content-Length field
+   value).
+   If the unrecoverable error is in a request message,
+   the server &MUST; respond with
    a <x:ref>400 (Bad Request)</x:ref> status code and then close the connection.
-   If this is a response message received by a proxy,
+   If it is in a response message received by a proxy,
    the proxy &MUST; close the connection to the server, discard the received
    response, and send a <x:ref>502 (Bad Gateway)</x:ref> response to the
    client.
-   If this is a response message received by a user agent,
+   If it is in a response message received by a user agent,
    the user agent &MUST; close the connection to the server and discard the
    received response.
   </t></li>
@@ -1412,8 +1417,9 @@ Transfer-Encoding: gzip, chunked
   <dd>See <xref target="gzip.coding"/>.</dd>
 </dl>
 <t>
-   The compression codings do not define any parameters. Their presence
-   &SHOULD; be treated as an error.
+   The compression codings do not define any parameters. The presence
+   of parameters with any of these compression codings &SHOULD; be treated
+   as an error.
 </t>
 </section>
 
@@ -2100,7 +2106,7 @@ Connection: close
 <section title="Security Considerations" anchor="security.considerations">
 <t>
    This section is meant to inform developers, information providers, and
-   users of known security considerations relevant to HTTP message syntax
+   users about known security considerations relevant to HTTP message syntax
    and parsing. Security considerations about HTTP semantics,
    content, and routing are addressed in <xref target="Semantics"/>.
 </t>
@@ -2194,7 +2200,8 @@ Connection: close
 <t>
    Extensions to the protocol might be used to mitigate the risk of unwanted
    modification of messages by intermediaries, even when the "https" scheme is
-   used. Integrity might be assured by using hash functions or digital
+   used. Integrity might be assured by using message authentication codes
+   or digital
    signatures that are selectively added to messages via extensible metadata
    fields.
 </t>
@@ -2957,7 +2964,7 @@ Connection: close
    connection management requirements specific to HTTP/1.1.
 </t>
 <t>
-   Prohibited generation of bare CRs outside of content.
+   Bare CRs have been prohibited outside of content.
    (<xref target="message.parsing"/>)
 </t>
 <t>