Having taken a look at the data structures I have come to the following conclusions:
1) The JSON service protocol can with minor changes be made generic to any sort of catenate log based notary protocol. 2) The log data format is so tightly optimized to the specific CT implementation that any change to the data structures is going to be very painful. The sort of changes I suggest making to the service protocol are pretty minor. The main change being that all the data needed to process a message should be in the JSON encoded structure. Relying on particular URL formats is considered to be very bad design practice (see the off my lawn draft). http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-01 URIs should be used as a way of routing messages to end points. Depending on data encoded in URIs is like depending on the format of an IP address or DNS name. It is a layer violation. We need to rev this protocol in any case so that a client can request a consistent set of data in one operation rather than attempt multiple retrievals and possibly get out of sync data. I propose breaking the service protocol out into a separate document Which can then be reused by other catenate notary style protocols. I think this will improve readability as well. The log data format has been designed to be as compact as possible and so a position based data structure is used. The internal data structures use fixed length codes and in some cases fixed length fields. This avoids wasted bytes which is important in the CT scenario but I would not want to be having to give court testimony based on those formats. Which is one of the primary purposes other uses of a notary are likely to involve. Even attempting a meta-notary based on this format is going to be difficult. Because a meta-notary is likely to be based on a skip-list or other sequential log type approach rather than a Merkle Tree. The practical upshot is that rather than just adding a version attribute to the service protocol we probably want to add a format parameter. Since I expect that the CT format will develop independent of other formats. -- Website: http://hallambaker.com/
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
