Extensible Markup Language Evidence Record Syntax (XMLERS)
draft-ietf-ltans-xmlers-11

3.1.2. Time-Stamp 

   Time-Stamp Token is an attestation generated by a TSA that a data 
   item existed at a certain time. The Time-Stamp Token is a signed data 
   object that contains the hash value, the identity of the TSA, and the 
   exact time (obtained from trusted time source) of Time-Stamping. This 
   proves that the given data existed before the time of Time-Stamping. 
   For example, [RFC3161] specifies a structure for signed Time-Stamp 
   Tokens in ASN.1 format. Since at the time being there is no standard 
   for an XML Time-Stamp, the following structure example is provided 
   (referring to the Entrust XML Schema for Time-Stamp 
   http://www.entrust.com/schemas/timestamp19protocol-20020207),

I think this URL should be made a proper reference

3.1.3. Cryptographic Information List 

   Digital certificates, CRLs, SCVP or OCSP-Responses needed to verify 
   the Time-Stamp Token SHOULD be stored in the Time-Stamp Token itself. 
   When this is not possible, such data MAY be stored in the 
   <CryptographicInformationList> element, each data object into a 

I think "is stored" is missing after "into".

   separate <CryptographicInformation> element, using a mandatory Order 
   attribute. 


In 4.1.1: the first mentioning of "URI" needs an Informative Reference.

In 4.1.2: the first mentioning of "UTF-8" needs an Informative Reference.

Ari Keränen helped me review this. Here are his comments:

There are some musts and mays (e.g., in Section 2.2 and 3) that could be capitalized (RFC2119'ised). I'd recommend going through all of them once more and capitalizing them when describing normative behavior.


2.1. Structure

         <EncryptionInformationType>
         <EncryptionInformationValue>

I guess these should be:

         <EncryptionInformationType />
         <EncryptionInformationValue />


     REQUIRED Order attribute to indicate the order within the parent
     element and an OPTIONAL Type attribute to indicate processing
     directions. 

It is a bit confusing to have an *element* with the name "attribute" (that is the case, right?) when the same text uses also the term "attribute" to refer to element's (XML) attributes. 


3.1.1. Hash Tree

   The newly calculated hash value is added to the next list of hashes

Should that be "concatenated" instead of "added"? (same issue is found multiple times in this section).



3.2.1. Generation of Hash Tree

   3. Group together items in the input list by the order of N 

"order of N" is not defined. Should that be "order of the hash tree"?

I agree with Sean's discuss on RFC2119 usage.

#1) addressed

#2) addressed

#3) addressed

#4) addressed

#5) Sec 2.1: Should probably also indicate how many of the fields can be included (i.e, match the +, ?, * in the schema to the text).

#6) I didn't see the changes for this one:

Sec 3.1.1: I put that hex string in to a couple of Base64 encoders and got:

QTk5OTNFMzYgNDcwNjgxNkEgQkEzRTI1NzEgNzg1MEMyNkMgOUNEMEQ4OUQ==

#7) addressed