[PATCH 03/14] capitalize key words according to RFC 2119

[Tay Ray Chuan <rctay89@gmail.com>]

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
 Documentation/technical/http-protocol.txt | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt
index 70a1648..55753bb 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -11,6 +11,10 @@ protocol URLs to smart URLs.  This permits all users to have the
 same published URL, and the peers automatically select the most
 efficient transport available to them.
 
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
+"OPTIONAL" in this document are to be interpreted as described in
+RFC 2119.
 
 URL Format
 ----------
@@ -29,7 +33,7 @@ supplied $GIT_URL string.
 
 Clients MUST strip a trailing '/', if present, from the user supplied
 $GIT_URL string to prevent empty path tokens ('//') from appearing
-in any URL sent to a server.  Compatible clients must expand
+in any URL sent to a server.  Compatible clients MUST expand
 '$GIT_URL/info/refs' as 'foo/info/refs' and not 'foo//info/refs'.
 
 
@@ -66,7 +70,7 @@ Session State
 -------------
 
 The Git over HTTP protocol (much like HTTP itself) is stateless
-from the perspective of the HTTP server side.  All state must be
+from the perspective of the HTTP server side.  All state MUST be
 retained and managed by the client process.  This permits simple
 round-robin load-balancing on the server side, without needing to
 worry about state management.
@@ -158,7 +162,7 @@ references by making a request for the special info/refs file of
 the repository.
 
 Dumb HTTP clients MUST NOT include search/query parameters when
-fetching the info/refs file.  (That is, '?' must not appear in the
+fetching the info/refs file.  (That is, '?' MUST NOT appear in the
 requested URL.)
 
    C: GET $GIT_URL/info/refs HTTP/1.0
@@ -390,7 +394,7 @@ The computation to select the minimal pack proceeds as follows
 
  (c) Start a queue, C_PENDING, ordered by commit time (popping newest
      first).  Add all client refs.  When a commit is popped from
-     the queue its parents should be automatically inserted back.
+     the queue its parents SHOULD be automatically inserted back.
      Commits MUST only enter the queue once.
 
  one compute step:
@@ -431,7 +435,7 @@ The computation to select the minimal pack proceeds as follows
 
      If the client has sent 256 HAVE commits and has not yet
      received one of those back from S_COMMON, or the client has
-     emptied C_PENDING it should include a "done" command to let
+     emptied C_PENDING it SHOULD include a "done" command to let
      the server know it won't proceed:
 
    C: 0009done
@@ -470,7 +474,7 @@ TODO: Document the pack based response
 
      The returned stream is the side-band-64k protocol supported
      by the git-upload-pack service, and the pack is embedded into
-     stream 1.  Progress messages from the server side may appear
+     stream 1.  Progress messages from the server side MAY appear
      in stream 2.
 
      Here a "closed set of objects" is defined to have at least
@@ -538,5 +542,6 @@ References
 ----------
 
 link:http://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)]
+link:http://www.ietf.org/rfc/rfc2119.txt[RFC 2119: Key words for use in RFCs to Indicate Requirement Levels]
 link:http://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1]
 
-- 
1.8.4.rc4.527.g303b16c