Changeset 698 for draft-ietf-httpbis/latest/p1-messaging.xml

Timestamp:

26/09/09 10:09:09 (13 years ago)

Author:

julian.reschke@…

Message:

editorial: enhance readability of header introductions

File:

• draft-ietf-httpbis/latest/p1-messaging.xml (modified) (5 diffs)

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

@@ -2554 +2554 @@
 <t>
    The "Content-Length" entity-header field indicates the size of the
-   entity-body, in number of OCTETs, sent to the recipient or,
-   in the case of the HEAD method, the size of the entity-body that
-   would have been sent had the request been a GET.
+   entity-body, in number of OCTETs. In the case of responses to the HEAD
+   method, it indicates the size of the entity-body that would have been sent
+   had the request been a GET.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/><iref primary="true" item="Grammar" subitem="Content-Length-v"/>
@@ -2674 +2674 @@
 <t>
    The "Host" request-header field specifies the Internet host and port
-   number of the resource being requested, as obtained from the original
-   URI given by the user or referring resource (generally an http URI,
-   as described in <xref target="http.uri"/>). The Host field value &MUST; represent
-   the naming authority of the origin server or gateway given by the
-   original URL. This allows the origin server or gateway to
-   differentiate between internally-ambiguous URLs, such as the root "/"
-   URL of a server for multiple host names on a single IP address.
+   number of the resource being requested, allowing the origin server or
+   gateway to differentiate between internally-ambiguous URLs, such as the root
+   "/" URL of a server for multiple host names on a single IP address.
+</t>
+<t>    
+   The Host field value &MUST; represent the naming authority of the origin
+   server or gateway given by the original URL obtained from the user or
+   referring resource (generally an http URI, as described in
+   <xref target="http.uri"/>).
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/><iref primary="true" item="Grammar" subitem="Host-v"/>
@@ -2724 +2726 @@
 <t>
    The "TE" request-header field indicates what extension transfer-codings
-   it is willing to accept in the response and whether or not it is
-   willing to accept trailer fields in a chunked transfer-coding. Its
-   value may consist of the keyword "trailers" and/or a comma-separated
+   it is willing to accept in the response, and whether or not it is
+   willing to accept trailer fields in a chunked transfer-coding.
+</t>
+<t>
+   Its value may consist of the keyword "trailers" and/or a comma-separated
    list of extension transfer-coding names with optional accept
    parameters (as described in <xref target="transfer.codings"/>).
@@ -2838 +2842 @@
   <x:anchor-alias value="Transfer-Encoding-v"/>
 <t>
-   The "Transfer-Encoding" general-header field indicates what (if any)
-   type of transformation has been applied to the message body in order
-   to safely transfer it between the sender and the recipient. This
-   differs from the content-coding in that the transfer-coding is a
-   property of the message, not of the entity.
+   The "Transfer-Encoding" general-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.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/><iref primary="true" item="Grammar" subitem="Transfer-Encoding-v"/>
@@ -2874 +2878 @@
 <t>
    The "Upgrade" general-header field allows the client to specify what
-   additional communication protocols it supports and would like to use
-   if the server finds it appropriate to switch protocols. The server
-   &MUST; use the Upgrade header field within a 101 (Switching Protocols)
-   response to indicate which protocol(s) are being switched.
+   additional communication protocols it would like to use, if the server 
+   chooses to switch protocols. Additionally, the server &MUST; use the Upgrade
+   header field within a 101 (Switching Protocols) response to indicate which
+   protocol(s) are being switched to.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Upgrade"/><iref primary="true" item="Grammar" subitem="Upgrade-v"/>