Extensible Markup Language Evidence Record Syntax (XMLERS)
RFC 6283

Note: This ballot was opened for revision 11 and is now closed.

(Tim Polk) Yes

(Jari Arkko) No Objection

Comment (2011-02-03)
No email
send info
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


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

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"?

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) No Objection

Comment (2011-01-17 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I agree with Sean's discuss on RFC2119 usage.

(Adrian Farrel) No Objection

(Russ Housley) No Objection

(Alexey Melnikov) (was Discuss) No Objection

Comment (2011-01-19)
No email
send info
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 

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 

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.

(Dan Romascanu) No Objection

(Peter Saint-Andre) (was Discuss) No Objection

(Robert Sparks) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2011-01-24)
No email
send info
#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:


#7) addressed