Gave guidance if there are multiple instances of the same header field.

specs/source/http-signatures/index.xml

@@ -1,10 +1,10 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN" "http://xml.resource.org/authoring/rfc2629.dtd" [
-  <!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
-  <!ENTITY rfc2616 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
-  <!ENTITY rfc2617 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml">
-  <!ENTITY rfc4648 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
-  <!ENTITY rfc5246 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
+  <!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
+  <!ENTITY rfc2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
+  <!ENTITY rfc2617 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml">
+  <!ENTITY rfc4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
+  <!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
 ]>
 <?xml-stylesheet type="text/xsl" href="rfc2629.xsl" ?>
 <?rfc compact="yes" ?>
@@ -164,7 +164,7 @@ mechanisms is listed below.
      <t>
 OPTIONAL.  The `headers` parameter is used to specify the list of HTTP headers
 used to sign the request.  If specified, it should be a lowercased,
-quoted list of HTTP header names, separated by a single space character.  
+quoted list of HTTP header fields, separated by a single space character.  
 By default, only one HTTP header is signed, which is the `Date` header.  
 Note that the list order is important, and MUST be specified in the order 
 the values are concatenated together during signing. 
@@ -173,13 +173,13 @@ the values are concatenated together during signing.
 
     <section anchor="signature" title="signature">
      <t>
-REQUIRED.  The `signature` parameter is a `Base64` encoded digital signature,
-as described in <xref target="RFC4648">RFC 4648</xref>, Section 4.
-generated by the client. The client uses the `algorithm` and `headers` request
-parameters to form a canonicalized `signing string`.  This `signing string` is
-then signed with the key associated with `keyId` and the algorithm
-corresponding to `algorithm`.  The `signature` parameter is then set to the
-`Base64` encoding of the signature.
+REQUIRED.  The `signature` parameter is a base 64 encoded digital signature,
+as described in <xref target="RFC4648">RFC 4648</xref>, 
+<eref target="http://tools.ietf.org/html/rfc4648#section-4">Section 4</eref>.
+The client uses the `algorithm` and `headers` request parameters to form a 
+canonicalized `signing string`.  This `signing string` is then signed with the 
+key associated with `keyId` and the algorithm corresponding to `algorithm`.
+The `signature` parameter is then set to the base 64 encoding of the signature.
      </t>
     </section>
    </section>
@@ -188,10 +188,10 @@ corresponding to `algorithm`.  The `signature` parameter is then set to the
 
    <t>
 In order to generate the string that is signed with a key, the client MUST take
-the values of each HTTP header specified by `headers` in the order they appear.
-It is out of scope for this document to dictate what headers a service provider
-will want to enforce, but service providers SHOULD at minimum include the
-request line, Host, and Date headers.
+the values of each HTTP header field specified by `headers` in the order they 
+appear. It is out of scope for this document to dictate what header fields 
+an application will want to enforce, but implementers SHOULD at minimum 
+include the request line, Host, and Date header fields.
    </t>
    <t>
 To include the HTTP request line in the signature calculation, use the 
@@ -203,11 +203,15 @@ headers in useful signature calculation, it is deemed simpler to use
 
     <list style="numbers">
      <t>
-If the header name is not `(request-line)` then append the lowercased header
-name followed with an ASCII colon `:` and an ASCII space ` `.
+If the header field is not `(request-line)` then append the lowercased header
+name followed with an ASCII colon `:`, an ASCII space ` `, and the value.
+The value MUST NOT be modified or canonicalized in any way. If there are 
+multiple instances of the same header field, all header field values associated 
+with the header field MUST be concatenated and used in the order in which they 
+will appear in the transmitted HTTP message.
      </t>
      <t>
-If the header name is `(request-line)` then appened the HTTP request line,
+If the header field is `(request-line)` then appened the HTTP request line,
 otherwise append the header value. 
      </t>
      <t>