fixed misc. typos and grammar issues in protocol spec doc

2 files changed, 82 insertions, 83 deletions

diff --git a/doc/protocol-binary.txt b/doc/protocol-binary.txt
index aa9ee66..710a69a 100644
--- a/doc/protocol-binary.txt
+++ b/doc/protocol-binary.txt
@@ -117,12 +117,12 @@ Internet-Draft          Memcache Binary Protocol             August 2008
 
    Memcache is a high performance key-value cache.  It is intentionally
    a dumb cache, optimized for speed only.  Applications using memcache
-   do not rely on it for data -- a persistent database with guaranteed
-   reliability is strongly recommended -- but applications can run much
-   faster when cached data is available in memcache.
+   should not rely on it for data -- a persistent database with
+   guaranteed reliability is strongly recommended -- but applications
+   can run much faster when cached data is available in memcache.
 
-   Memcache was originally written to make LiveJournal [LJ] go faster.
-   It now powers all of the fastest web sites that you love.
+   Memcache was originally written to make LiveJournal [LJ] faster.  It
+   now powers all of the fastest web sites that you love.
 
 1.1.  Conventions Used In This Document
 
@@ -145,7 +145,7 @@ Internet-Draft          Memcache Binary Protocol             August 2008
        /                                                               /
        +---------------+---------------+---------------+---------------+
      24/ COMMAND-SPECIFIC EXTRAS (as needed)                           /
-      +/  (note length in th extras length header field)               /
+      +/  (note length in the extras length header field)              /
        +---------------+---------------+---------------+---------------+
       m/ Key (as needed)                                               /
       +/  (note length in key length header field)                     /
@@ -231,7 +231,7 @@ Internet-Draft          Memcache Binary Protocol             August 2008
    Reserved            Really reserved for future use (up for grabs).
    Total body length   Length in bytes of extra + key + value.
    Opaque              Will be copied back to you in the response.
-   CAS                 Data version check
+   CAS                 Data version check.
 
 
 3.  Defined Values
@@ -243,10 +243,10 @@ Internet-Draft          Memcache Binary Protocol             August 2008
 
    Magic byte / version.  For each version of the protocol, we'll use a
    different request/response value pair.  This is useful for protocol
-   analyzers to know what a packet is in isolation from which direction
-   it is moving.  Note that it is common to run a memcached instance on
-   a host that also runs an application server.  Such a host will both
-   send and receive memcache packets.
+   analyzers to distinguish the nature of the packet from the direction
+   which it is moving.  Note, it is common to run a memcached instance
+   on a host that also runs an application server.  Such a host will
+   both send and receive memcache packets.
 
    The version should hopefully correspond only to different meanings of
    the command byte.  In an ideal world, we will not change the header
@@ -255,7 +255,7 @@ Internet-Draft          Memcache Binary Protocol             August 2008
 
    Traffic analysis tools are encouraged to identify memcache packets
    and provide detailed interpretation if the magic bytes are recognized
-   and otherwise to provide a generic breakdown of the packet.  Note
+   and otherwise to provide a generic breakdown of the packet.  Note,
    that the key and value positions can always be identified even if the
    magic byte or command opcode are not recognized.
 
@@ -265,7 +265,7 @@ Internet-Draft          Memcache Binary Protocol             August 2008
    0x0000  No error
    0x0001  Key not found
    0x0002  Key exists
-   0x0003  Value too big
+   0x0003  Value too large
    0x0004  Invalid arguments
    0x0005  Item not stored
    0x0081  Unknown command
@@ -315,11 +315,11 @@ Internet-Draft          Memcache Binary Protocol             August 2008
 4.1.  Introduction
 
    All communication is initiated by a request from the client, and the
-   server will respond to each request with zero or multiple packets
-   from each request.  If the server respond with a message with a non-
-   nil status code, the body of the packet contains a textual error
-   message.  If the status code is nil, the command opcode will define
-   the layout of the body of the message.
+   server will respond to each request with zero or multiple packets for
+   each request.  If the status code of a response packet is non-nil,
+   the body of the packet will contain a textual error message.  If the
+   status code is nil, the command opcode will define the layout of the
+   body of the message.
 
 4.1.1.  Example
 
@@ -423,16 +423,16 @@ Internet-Draft          Memcache Binary Protocol             August 2008
    key into the response packet.
 
    You're not guaranteed a response to a getq/getkq cache hit until you
-   send a non-getq/getkq command later, which uncorks the server which
+   send a non-getq/getkq command later, which uncorks the server and
    bundles up IOs to send to the client in one go.
 
    Clients should implement multi-get (still important for reducing
    network roundtrips!) as n pipelined requests, the first n-1 being
-   getq/getkq, the last being a regular get/getk. that way you're
+   getq/getkq, the last being a regular get/getk.  That way you're
    guaranteed to get a response, and you know when the server's done.
-   you can also do the naive thing and send n pipelined get/getks, but
+   You can also do the naive thing and send n pipelined get/getks, but
    then you could potentially get back a lot of "NOT_FOUND" error code
-   packets. alternatively, you can send 'n' getq/getkqs, followed by a
+   packets.  Alternatively, you can send 'n' getq/getkqs, followed by a
    'noop' command.
 
 4.2.1.  Example
@@ -605,7 +605,7 @@ Internet-Draft          Memcache Binary Protocol             August 2008
    Extras              :
      Flags      (24-27): 0xdeadbeef
    Key          (28-32): The textual string: "Hello"
-   Value        (33-37): The textual string "World"
+   Value        (33-37): The textual string: "World"
 
 
 
@@ -646,7 +646,7 @@ Internet-Draft          Memcache Binary Protocol             August 2008
 
    Replace MUST fail if the item doesn't exist.
 
-   Set should store the data unconditionally if the item exists or not..
+   Set should store the data unconditionally if the item exists or not.
 
 4.3.1.  Example
 
@@ -729,9 +729,9 @@ Stone & Norbye            Expires March 1, 2009                [Page 13]
 Internet-Draft          Memcache Binary Protocol             August 2008
 
 
-   The response-packet contains no extra data, and the result of
+   The response-packet contains no extra data, and the result of the
    operation is signaled through the status code.  If the command
-   succeed, the CAS value for the item is returned in the CAS-field of
+   succeeds, the CAS value for the item is returned in the CAS-field of
    the packet.
 
    Successful add response:
@@ -772,7 +772,7 @@ Internet-Draft          Memcache Binary Protocol             August 2008
 
 4.4.  Delete
 
-      MUST NOT have extras
+      MUST NOT have extras.
       MUST have key.
       MUST NOT have value.
 
@@ -787,7 +787,7 @@ Internet-Draft          Memcache Binary Protocol             August 2008
 
 4.4.1.  Example
 
-   The following figure shows a delete message for the item "Hello"
+   The following figure shows a delete message for the item "Hello".
 
    Delete request:
 
@@ -828,7 +828,7 @@ Internet-Draft          Memcache Binary Protocol             August 2008
    Key                 : The textual string "Hello"
    Value               : None
 
-   The response-packet contains no extra data, and the result of
+   The response-packet contains no extra data, and the result of the
    operation is signaled through the status code.
 
 
@@ -1105,7 +1105,7 @@ Internet-Draft          Memcache Binary Protocol             August 2008
    Key                 : None
    Value               : None
 
-   The response-packet contains no extra data, and the result of
+   The response-packet contains no extra data, and the result of the
    operation is signaled through the status code.  The server will then
    close the connection.
 
@@ -1121,7 +1121,7 @@ Stone & Norbye            Expires March 1, 2009                [Page 20]
 Internet-Draft          Memcache Binary Protocol             August 2008
 
 
-      MAY have extras
+      MAY have extras.
       MUST NOT have key.
       MUST NOT have value.
 
@@ -1137,10 +1137,10 @@ Internet-Draft          Memcache Binary Protocol             August 2008
        +---------------+---------------+---------------+---------------+
      Total 4 bytes
 
-   Flush the items in the cache now or sometime in the future specified
-   by the expiration field.  See the documentation of the textual
-   protocol for the full description on how to specify the expiration
-   time.
+   Flush the items in the cache now or some time in the future as
+   specified by the expiration field.  See the documentation of the
+   textual protocol for the full description on how to specify the
+   expiration time.
 
 4.7.1.  Example
 
@@ -1214,7 +1214,7 @@ Internet-Draft          Memcache Binary Protocol             August 2008
    Key                 : None
    Value               : None
 
-   The response-packet contains no extra data, and the result of
+   The response-packet contains no extra data, and the result of the
    operation is signaled through the status code.
 
 4.8.  noop
@@ -1269,7 +1269,7 @@ Internet-Draft          Memcache Binary Protocol             August 2008
    Key                 : None
    Value               : None
 
-   The response-packet contains no extra data, and the result of
+   The response-packet contains no extra data, and the result of the
    operation is signaled through the status code.
 
 4.9.  version
@@ -1280,7 +1280,7 @@ Internet-Draft          Memcache Binary Protocol             August 2008
 
    Request the server version.
 
-   The server respond with a packet containing the version string in the
+   The server responds with a packet containing the version string in
 
 
 
@@ -1289,7 +1289,7 @@ Stone & Norbye            Expires March 1, 2009                [Page 23]
 Internet-Draft          Memcache Binary Protocol             August 2008
 
 
-   body with the following format: "x.y.z"
+   the body with the following format: "x.y.z"
 
 4.9.1.  Example
 
@@ -1443,7 +1443,7 @@ Internet-Draft          Memcache Binary Protocol             August 2008
    Key          (24-28): The textual string "Hello"
    Value        (29)   : "!"
 
-   The response-packet contains no extra data, and the result of
+   The response-packet contains no extra data, and the result of the
    operation is signaled through the status code.
 
 
@@ -1465,10 +1465,10 @@ Internet-Draft          Memcache Binary Protocol             August 2008
 
    Request server statistics.  Without a key specified the server will
    respond with a "default" set of statistics information.  Each piece
-   of statistical information is returned in it's own packet (key
+   of statistical information is returned in its own packet (key
    contains the name of the statistical item and the body contains the
-   value in ASCII format).  The sequence of return packet is terminated
-   with a packet with no key and no value.
+   value in ASCII format).  The sequence of return packets is terminated
+   with a packet that contains no key and no value.
 
 4.11.1.  Example
 
@@ -1547,9 +1547,9 @@ Internet-Draft          Memcache Binary Protocol             August 2008
    Key                 : None
    Value               : None
 
-   The server will send send each value in a separate packet with an
-   "empty" packet (no key / no value) to terminate the sequence.  Each
-   of the response packets look like the following example:
+   The server will send each value in a separate packet with an "empty"
+   packet (no key / no value) to terminate the sequence.  Each of the
+   response packets look like the following example:
 
 
 
diff --git a/doc/protocol-binary.xml b/doc/protocol-binary.xml
index 1b6fe84..89f5ce4 100644
--- a/doc/protocol-binary.xml
+++ b/doc/protocol-binary.xml
@@ -58,14 +58,14 @@
     <section anchor="introduction" title="Introduction">
       <t>
         Memcache is a high performance key-value cache. It is intentionally a
-        dumb cache, optimized for speed only. Applications using memcache do
+        dumb cache, optimized for speed only. Applications using memcache should
         not rely on it for data -- a persistent database with guaranteed
         reliability is strongly recommended -- but applications can run much
         faster when cached data is available in memcache.
       </t>
       <t>
         Memcache was originally written to make
-        <xref target="LJ">LiveJournal</xref> go faster. It now powers all of
+        <xref target="LJ">LiveJournal</xref> faster. It now powers all of
         the fastest web sites that you love.
       </t>
       <section anchor="conventions" title="Conventions Used In This Document">
@@ -92,7 +92,7 @@
     /                                                               /
     +---------------+---------------+---------------+---------------+
   24/ COMMAND-SPECIFIC EXTRAS (as needed)                           /
-   +/  (note length in th extras length header field)               /
+   +/  (note length in the extras length header field)              /
     +---------------+---------------+---------------+---------------+
    m/ Key (as needed)                                               /
    +/  (note length in key length header field)                     /
@@ -161,7 +161,7 @@
           <t hangText="Reserved">Really reserved for future use (up for grabs).</t>
           <t hangText="Total body length">Length in bytes of extra + key + value.</t>
           <t hangText="Opaque">Will be copied back to you in the response.</t>
-          <t hangText="CAS">Data version check</t>
+          <t hangText="CAS">Data version check.</t>
         </list>
       </t>
     </section>
@@ -178,10 +178,10 @@
         <t>
           Magic byte / version. For each version of the protocol, we'll use a
           different request/response value pair. This is useful for protocol
-          analyzers to know what a packet is in isolation from which direction
-          it is moving. Note that it is common to run a memcached instance on a
-          host that also runs an application server. Such a host will both send
-          and receive memcache packets.
+          analyzers to distinguish the nature of the packet from the direction
+          which it is moving. Note, it is common to run a memcached instance on
+	  a host that also runs an application server. Such a host will both
+	  send and receive memcache packets.
         </t>
 
         <t>
@@ -194,7 +194,7 @@
         <t>
           Traffic analysis tools are encouraged to identify memcache packets
           and provide detailed interpretation if the magic bytes are recognized
-          and otherwise to provide a generic breakdown of the packet. Note that
+          and otherwise to provide a generic breakdown of the packet. Note, that
           the key and value positions can always be identified even if the magic
           byte or command opcode are not recognized.
         </t>
@@ -207,7 +207,7 @@
           <t hangText="0x0000">No error</t>
           <t hangText="0x0001">Key not found</t>
           <t hangText="0x0002">Key exists</t>
-          <t hangText="0x0003">Value too big</t>
+          <t hangText="0x0003">Value too large</t>
           <t hangText="0x0004">Invalid arguments</t>
           <t hangText="0x0005">Item not stored</t>
           <t hangText="0x0081">Unknown command</t>
@@ -256,11 +256,10 @@
         <t>
         All communication is initiated by a request from the client,
         and the server will respond to each request with zero or
-        multiple packets from each request. If the server respond with
-        a message with a non-nil status code, the body of the packet
-        contains a textual error message. If the status code is nil,
-        the command opcode will define the layout of the body of the
-        message.
+	multiple packets for each request. If the status code of a response
+	packet is non-nil, the body of the packet will contain a textual error
+	message. If the status code is nil, the command opcode will define the
+	layout of the body of the message.
         </t>
         <section anchor="command-introduction-example" title="Example">
             <t>
@@ -374,18 +373,18 @@ Value        (24-32): The textual string "Not found"
         <t>
           You're not guaranteed a response to a getq/getkq cache hit until
           you send a non-getq/getkq command later, which uncorks the
-          server which bundles up IOs to send to the client in one go.
+          server and bundles up IOs to send to the client in one go.
         </t>
 
         <t>
           Clients should implement multi-get (still important for
           reducing network roundtrips!) as n pipelined requests, the
           first n-1 being getq/getkq, the last being a regular
-          get/getk.  that way you're guaranteed to get a response, and
-          you know when the server's done.  you can also do the naive
+          get/getk.  That way you're guaranteed to get a response, and
+          you know when the server's done.  You can also do the naive
           thing and send n pipelined get/getks, but then you could potentially
           get back a lot of "NOT_FOUND" error code packets.
-          alternatively, you can send 'n' getq/getkqs, followed by a
+          Alternatively, you can send 'n' getq/getkqs, followed by a
           'noop' command.
         </t>
 
@@ -529,7 +528,7 @@ CAS          (16-23): 0x0000000000000001
 Extras              :
   Flags      (24-27): 0xdeadbeef
 Key          (28-32): The textual string: "Hello"
-Value        (33-37): The textual string "World"
+Value        (33-37): The textual string: "World"
             </artwork>
           </figure>
         </section>
@@ -582,7 +581,7 @@ Value        (33-37): The textual string "World"
 
         <t>
         Set should store the data unconditionally if the item exists
-        or not..
+        or not.
         </t>
 
         <section anchor="command-set-example" title="Example">
@@ -646,9 +645,9 @@ Value        (37-41): The textual string "World"
              </artwork>
            </figure>
            <t>
-        The response-packet contains no extra data, and the result of
+        The response-packet contains no extra data, and the result of the
         operation is signaled through the status code. If the command
-        succeed, the CAS value for the item is returned in the CAS-field
+        succeeds, the CAS value for the item is returned in the CAS-field
         of the packet.
            </t>
            <figure>
@@ -695,7 +694,7 @@ Value               : None
       <section anchor="command-delete" title="Delete">
         <t>
         <list style="empty">
-          <t>MUST NOT have extras</t>
+          <t>MUST NOT have extras.</t>
           <t>MUST have key.</t>
           <t>MUST NOT have value.</t>
         </list>
@@ -707,7 +706,7 @@ Value               : None
 
         <section anchor="command-delete-example" title="Example">
           <t>The following figure shows a delete message for the
-            item "Hello"</t>
+            item "Hello".</t>
           <figure>
             <preamble>Delete request:</preamble>
             <artwork>
@@ -750,7 +749,7 @@ Value               : None
             </artwork>
           </figure>
           <t>
-            The response-packet contains no extra data, and the result of
+            The response-packet contains no extra data, and the result of the
             operation is signaled through the status code.
           </t>
         </section>
@@ -984,7 +983,7 @@ Value               : None
             </artwork>
           </figure>
           <t>
-            The response-packet contains no extra data, and the result of
+            The response-packet contains no extra data, and the result of the
             operation is signaled through the status code. The server will
             then close the connection.
           </t>
@@ -994,7 +993,7 @@ Value               : None
       <section anchor="command-flush" title="Flush">
         <t>
           <list style="empty">
-            <t>MAY have extras</t>
+            <t>MAY have extras.</t>
             <t>MUST NOT have key.</t>
             <t>MUST NOT have value.</t>
           </list>
@@ -1018,7 +1017,7 @@ Value               : None
           </artwork>
         </figure>
         <t>
-            Flush the items in the cache now or sometime in the future
+            Flush the items in the cache now or some time in the future as
             specified by the expiration field. See the documentation of the
             textual protocol for the full description on how to specify the
             expiration time.
@@ -1068,7 +1067,7 @@ Value               : None
           </artwork>
         </figure>
           <t>
-            The response-packet contains no extra data, and the result of
+            The response-packet contains no extra data, and the result of the
             operation is signaled through the status code.
           </t>
         </section>
@@ -1123,7 +1122,7 @@ Value               : None
             </artwork>
           </figure>
           <t>
-            The response-packet contains no extra data, and the result of
+            The response-packet contains no extra data, and the result of the
             operation is signaled through the status code.
           </t>
         </section>
@@ -1142,7 +1141,7 @@ Value               : None
           Request the server version.
         </t>
         <t>
-	  The server respond with a packet containing the version string
+	  The server responds with a packet containing the version string
 	  in the body with the following format: "x.y.z"
         </t>
         <section anchor="command-version-example" title="Example">
@@ -1280,7 +1279,7 @@ Value        (29)   : "!"
             </artwork>
           </figure>
           <t>
-            The response-packet contains no extra data, and the result of
+            The response-packet contains no extra data, and the result of the
             operation is signaled through the status code.
           </t>
         </section>
@@ -1298,10 +1297,10 @@ Value        (29)   : "!"
         <t>
 	  Request server statistics. Without a key specified the server will
           respond with a "default" set of statistics information. Each piece
-          of statistical information is returned in it's own packet (key
+          of statistical information is returned in its own packet (key
           contains the name of the statistical item and the body contains the
-          value in ASCII format). The sequence of return packet is terminated
-          with a packet with no key and no value.
+          value in ASCII format). The sequence of return packets is terminated
+          with a packet that contains no key and no value.
         </t>
         <section anchor="command-stat-example" title="Example">
             <t>The following example requests all statistics from the server</t>
@@ -1342,7 +1341,7 @@ Value               : None
             </artwork>
           </figure>
           <t>
-              The server will send send each value in a separate packet with
+              The server will send each value in a separate packet with
               an "empty" packet (no key / no value) to terminate the sequence.
               Each of the response packets look like the following example:
          </t>