Subject: spelling, grammar, and other simple fixes

From: Dan Winship <[email-masked]>
Date: Thu, 26 Jan 2012 08:50:46 -0500

The first attached patch contains a bunch of pretty obvious fixes.

The second patch attempts to fix the hierarchy breakage introduced in p6
in -18 while adding the subsections to 3.6. (As can be seen in the table
of contents here:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-httpbis-p6-cache-18.txt).

I think the fix is correct, but I can't get the html/txt versions to
build so I'm not totally sure.

-- Dan
diff --git a/draft-ietf-httpbis/latest/p1-messaging.xml b/draft-ietf-httpbis/latest/p1-messaging.xml
index 29b14f5..3ff4e42 100644
--- a/draft-ietf-httpbis/latest/p1-messaging.xml
+++ b/draft-ietf-httpbis/latest/p1-messaging.xml
@@ -895,7 +895,7 @@ Content-Type: text/plain
 </t>
 <t>
    Intermediaries that process HTTP messages (i.e., all intermediaries
-   other than those acting as a tunnel) &MUST; send their own HTTP-Version
+   other than those acting as tunnels) &MUST; send their own HTTP-Version
    in forwarded messages.  In other words, they &MUST-NOT; blindly
    forward the first line of an HTTP message without ensuring that the
    protocol version matches what the intermediary understands, and
@@ -2793,7 +2793,7 @@ Host: www.example.org
         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 is not be construed as preventing a server from
+        requirement should not be construed as preventing a server from
         defending itself against denial-of-service attacks, or from
         badly broken client implementations.
       </t>
@@ -3088,7 +3088,7 @@ Host: www.example.org
   <x:anchor-alias value="te-ext"/>
 <t>
    The "TE" header field indicates what extension transfer-codings
-   it is willing to accept in the response, and whether or not it is
+   the client 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>
@@ -3156,7 +3156,7 @@ Host: www.example.org
 </t>
 <t>
    If the TE field-value is empty or if no TE field is present, the only
-   transfer-coding is "chunked". A message with no transfer-coding is
+   acceptable transfer-coding is "chunked". A message with no transfer-coding is
    always acceptable.
 </t>
 </section>
@@ -3248,7 +3248,7 @@ Host: www.example.org
 </artwork></figure>
 <t>
    The Upgrade header field is intended to provide a simple mechanism
-   for transition from HTTP/1.1 to some other, incompatible protocol. It
+   for transitioning from HTTP/1.1 to some other, incompatible protocol. It
    does so by allowing the client to advertise its desire to use another
    protocol, such as a later version of HTTP with a higher major version
    number, even though the current request has been made using HTTP/1.1.
@@ -3837,7 +3837,7 @@ Host: www.example.org
    default configuration).
 </t>
 <t>
-   Users of a proxy need to be aware that proxies are no trustworthier than
+   Users of a proxy need to be aware that proxies are no more trustworthy than
    the people who run them; HTTP itself cannot solve this problem.
 </t>
 <t>
@@ -4856,7 +4856,7 @@ Zhong Yu.
    We would expect a general-purpose HTTP/1.1 server to understand
    any valid request in the format of HTTP/1.0 and respond appropriately
    with an HTTP/1.1 message that only uses features understood (or
-   safely ignored) by HTTP/1.0 clients.  Likewise, would expect
+   safely ignored) by HTTP/1.0 clients.  Likewise, we would expect
    an HTTP/1.1 client to understand any valid HTTP/1.0 response.
 </t>
 <t>
diff --git a/draft-ietf-httpbis/latest/p2-semantics.xml b/draft-ietf-httpbis/latest/p2-semantics.xml
index 7fdf4a0..441806c 100644
--- a/draft-ietf-httpbis/latest/p2-semantics.xml
+++ b/draft-ietf-httpbis/latest/p2-semantics.xml
@@ -2562,7 +2562,7 @@ Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
 <t>
    Clients can use the Date header field as well; in order to keep request
    messages small, they are advised not to include it when it doesn't convey
-   any useful information (as it is usually the case for requests that do not
+   any useful information (as is usually the case for requests that do not
    contain a payload).
 </t>
 <t>
@@ -2753,7 +2753,7 @@ Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
    TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>)
    methods to limit the number of times that the request is forwarded by
    proxies. This can be useful when the client is attempting to
-   trace a request which appears to be failing or looping in mid-chain.
+   trace a request which appears to be failing or looping mid-chain.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/>
   <x:ref>Max-Forwards</x:ref> = 1*<x:ref>DIGIT</x:ref>
@@ -2825,7 +2825,7 @@ Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
    Unavailable) response to indicate how long the service is expected to
    be unavailable to the requesting client. This field &MAY; also be used
    with any 3xx (Redirection) response to indicate the minimum time the
-   user-agent is asked wait before issuing the redirected request.
+   user-agent is asked to wait before issuing the redirected request.
 </t>
 <t>
    The value of this field can be either an HTTP-date or an integer number
@@ -3346,7 +3346,7 @@ Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
 <t>
    The User-Agent (<xref target="header.user-agent"/>) or Server (<xref
    target="header.server"/>) header fields can sometimes be used to determine
-   that a specific client or server have a particular security hole which might
+   that a specific client or server has a particular security hole which might
    be exploited. Unfortunately, this same information is often used for other
    valuable purposes for which HTTP currently has no better mechanism.
 </t>
diff --git a/draft-ietf-httpbis/latest/p3-payload.xml b/draft-ietf-httpbis/latest/p3-payload.xml
index 9473b3a..77be56c 100644
--- a/draft-ietf-httpbis/latest/p3-payload.xml
+++ b/draft-ietf-httpbis/latest/p3-payload.xml
@@ -455,7 +455,7 @@
 </t>
 <t>
    Names of content codings &MUST-NOT; overlap with names of transfer codings
-   (&transfer-codings;), unless the encoding transformation is identical (as it
+   (&transfer-codings;), unless the encoding transformation is identical (as
    is the case for the compression codings defined in
    &compression-codings;).
 </t>
@@ -857,7 +857,7 @@
 </t>
 <t>
    Server-driven negotiation allows the user agent to specify its preferences,
-   but it cannot expect responses to always honour them. For example, the origin
+   but it cannot expect responses to always honor them. For example, the origin
    server might not implement server-driven negotiation, or it might decide that
    sending a response that doesn't conform to them is better than sending a 406
    (Not Acceptable) response.
@@ -1597,7 +1597,7 @@
 
 <section title="Privacy Issues Connected to Accept Header Fields" anchor="privacy.issues.connected.to.accept.header.fields">
 <t>
-   Accept headers fields can reveal information about the user to all
+   Accept header fields can reveal information about the user to all
    servers which are accessed. The Accept-Language header field in particular
    can reveal information the user would consider to be of a private
    nature, because the understanding of particular languages is often
diff --git a/draft-ietf-httpbis/latest/p4-conditional.xml b/draft-ietf-httpbis/latest/p4-conditional.xml
index b358237..caba10d 100644
--- a/draft-ietf-httpbis/latest/p4-conditional.xml
+++ b/draft-ietf-httpbis/latest/p4-conditional.xml
@@ -865,7 +865,7 @@ Content-Encoding: gzip
 </artwork></figure>
 <t>
    The result of a request having both an If-Match header field and
-   either an If-None-Match or an If-Modified-Since header fields is
+   either an If-None-Match or an If-Modified-Since header field is
    undefined by this specification.
 </t>
 </section>
@@ -935,7 +935,7 @@ Content-Encoding: gzip
 </artwork></figure>
 <t>
    The result of a request having both an If-None-Match header field and
-   either an If-Match or an If-Unmodified-Since header fields is
+   either an If-Match or an If-Unmodified-Since header field is
    undefined by this specification.
 </t>
 </section>
@@ -1018,7 +1018,7 @@ Content-Encoding: gzip
 </t>
 <t>
    The result of a request having both an If-Modified-Since header field
-   and either an If-Match or an If-Unmodified-Since header fields is
+   and either an If-Match or an If-Unmodified-Since header field is
    undefined by this specification.
 </t>
 </section>
@@ -1057,7 +1057,7 @@ Content-Encoding: gzip
 <t>
    The result of a request having both an If-Unmodified-Since header
    field and either an If-None-Match or an If-Modified-Since header
-   fields is undefined by this specification.
+   field is undefined by this specification.
 </t>
 </section>
 
diff --git a/draft-ietf-httpbis/latest/p6-cache.xml b/draft-ietf-httpbis/latest/p6-cache.xml
index e6aa8f3..b2f1c20 100644
--- a/draft-ietf-httpbis/latest/p6-cache.xml
+++ b/draft-ietf-httpbis/latest/p6-cache.xml
@@ -549,7 +549,7 @@
       target="header.cache-control" />) does not appear in request or response
       header fields, and</t>
       <t>the "private" cache response directive (see <xref
-      target="cache-response-directive" /> does not appear in the response, if
+      target="cache-response-directive" />) does not appear in the response, if
       the cache is shared, and</t>
       <t>the "Authorization" header field (see &header-authorization;) does not
       appear in the request, if the cache is shared, unless the response
diff --git a/draft-ietf-httpbis/latest/p6-cache.xml b/draft-ietf-httpbis/latest/p6-cache.xml
index e6aa8f3..b2f1c20 100644
--- a/draft-ietf-httpbis/latest/p6-cache.xml
+++ b/draft-ietf-httpbis/latest/p6-cache.xml
@@ -1959,6 +1959,8 @@ Pragma: no-cache
 
 </section>
 
+</section>
+
 <section anchor="history.lists" title="History Lists">
 <t>
    User agents often have history mechanisms, such as "Back" buttons and
@@ -2115,7 +2117,6 @@ Pragma: no-cache
 <!--(END)-->
 <?ENDINC p6-cache.iana-warn-codes ?>
 </section>
-</section>

 <section title="Header Field Registration" anchor="header.field.registration">

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Jan 2012 15:56:46 +0100

> The first attached patch contains a bunch of pretty obvious fixes.

I applied those almost verbatim (-> 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1514>)

> http://tools.ietf.org/rfcdiff?url2=draft-ietf-httpbis-p6-cache-18.txt).

Good catch. Thanks alot.

> build so I'm not totally sure.

Sending patches for things like these makes it very convenient for me to 
apply them; thanks a lot.

In case others want to follow the example: please use the XML files in 
<http://trac.tools.ietf.org/wg/httpbis/trac/browser/draft-ietf-httpbis/latest> 
as basis.

Best regards, Julian