[PATCH 03/14] capitalize key words according to RFC 2119
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
Tay Ray Chuan <rctay89@gmail.com>