Changeset 697 for draft-ietf-httpbis/latest/p1-messaging.html

Timestamp:

Sep 25, 2009, 7:43:16 AM (10 years ago)

Author:

julian.reschke@…

Message:

editorial: rephrase header introductions ("the *-header field 'foobar'" -> "the "foobar" *-header field")

File:

• draft-ietf-httpbis/latest/p1-messaging.html (modified) (9 diffs)

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

@@ -1813 +1813 @@
       <div id="rfc.iref.h.6"></div>
       <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.connection" href="#header.connection">Connection</a></h2>
-      <p id="rfc.section.9.1.p.1">The general-header field "Connection" allows the sender to specify options that are desired for that particular connection
+      <p id="rfc.section.9.1.p.1">The "Connection" general-header field allows the sender to specify options that are desired for that particular connection
          and <em class="bcp14">MUST NOT</em> be communicated by proxies over further connections.
       </p>
@@ -1843 +1843 @@
       <div id="rfc.iref.h.7"></div>
       <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="header.content-length" href="#header.content-length">Content-Length</a></h2>
-      <p id="rfc.section.9.2.p.1">The entity-header field "Content-Length" indicates the size of the entity-body, in number of OCTETs, sent to the recipient
+      <p id="rfc.section.9.2.p.1">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.
       </p>
@@ -1861 +1861 @@
       <div id="rfc.iref.h.8"></div>
       <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h2>
-      <p id="rfc.section.9.3.p.1">The general-header field "Date" represents the date and time at which the message was originated, having the same semantics
+      <p id="rfc.section.9.3.p.1">The "Date" general-header field represents the date and time at which the message was originated, having the same semantics
          as orig-date in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section&nbsp;6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
       </p>
@@ -1898 +1898 @@
       <div id="rfc.iref.h.10"></div>
       <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="header.host" href="#header.host">Host</a></h2>
-      <p id="rfc.section.9.4.p.1">The request-header field "Host" specifies the Internet host and port number of the resource being requested, as obtained from
+      <p id="rfc.section.9.4.p.1">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 <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>). The Host field value <em class="bcp14">MUST</em> 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
@@ -1919 +1919 @@
       <div id="rfc.iref.h.11"></div>
       <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
-      <p id="rfc.section.9.5.p.1">The request-header field "TE" indicates what extension transfer-codings it is willing to accept in the response and whether
+      <p id="rfc.section.9.5.p.1">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 list of extension transfer-coding names with optional accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
@@ -1966 +1966 @@
       <div id="rfc.iref.h.12"></div>
       <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.trailer" href="#header.trailer">Trailer</a></h2>
-      <p id="rfc.section.9.6.p.1">The general field "Trailer" indicates that the given set of header fields is present in the trailer of a message encoded with
-         chunked transfer-coding.
+      <p id="rfc.section.9.6.p.1">The "Trailer" general-header field indicates that the given set of header fields is present in the trailer of a message encoded
+         with chunked transfer-coding.
       </p>
       <div id="rfc.figure.u.62"></div><pre class="inline"><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span>  <a href="#header.trailer" class="smpl">Trailer</a>   = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a>
@@ -1986 +1986 @@
       <div id="rfc.iref.h.13"></div>
       <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2>
-      <p id="rfc.section.9.7.p.1">The general-header "Transfer-Encoding" field indicates what (if any) type of transformation has been applied to the message
+      <p id="rfc.section.9.7.p.1">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.
@@ -2002 +2002 @@
       <div id="rfc.iref.h.14"></div>
       <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>
-      <p id="rfc.section.9.8.p.1">The general-header "Upgrade" 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 <em class="bcp14">MUST</em> use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched.
+      <p id="rfc.section.9.8.p.1">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 <em class="bcp14">MUST</em> use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched.
       </p>
       <div id="rfc.figure.u.65"></div><pre class="inline"><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a>   = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a>
@@ -2057 +2057 @@
       <div id="rfc.iref.h.15"></div>
       <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
-      <p id="rfc.section.9.9.p.1">The general-header field "Via" <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server
+      <p id="rfc.section.9.9.p.1">The "Via" general-header field <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server
          on requests, and between the origin server and the client on responses. It is analogous to the "Received" field defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
          of all senders along the request/response chain.