Following on from my last one that went out early...
2) The transactions add-chain and add-pre-chain only differ in the type of the data being exchanged. It would be more general to change the signature of the request message so that it had an explicit 'data type' 3) Shouldn't it be possible for a service to manage multiple logs? I would think this particularly important in the case of a retrieve-only log which is serving multiple logs. But the same point can be made about the add operation. 4) sha256_root_hash. Really? This should be an object that has an algorithm/data pair. Encoding the algorithm into the tag is going to make algorithm agility hard. 5) 'in decimal' This phrase crops up repeatedly and I don't think it means what is intended. All JSON integers are encoded in base 10. Using the term 'in decimal' is confusing as it is distinct from 'as a decimal' Integer 42 // An integer value in base ten Decimal 3.14 // A decimal fraction 6) The tree_size of the first tree, in decimal. In this context, tree_length would probably be easier to see the context. 7) https://<log server>/ct/v1/get-sth-consistency does not specify if the first and second tree_size identifiers are ordered or not. It is likely to result in problems if servers assume first > second or first < second. Either an order should be specified or there should be an explicit statement that it does not matter. 8) 0-based index Not clear to me from the reference section if this is a byte count or an object count. It should not be necessary to hunt through the spec to find out which. -- Website: http://hallambaker.com/
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
