> On Friday, June 01, 2007 7:00 AM James A. Donald wrote: > > Many protocols use some form of self describing data format, for example > ASN.1, XML, S expressions, and bencoding. > > Why? > > Presumably both ends of the conversation have negotiated what protocol > version they are using (and if they have not, you have big problems) and > when they receive data, they need to get the data they expect. If they > are looking for list of integer pairs, and they get a integer string > pairs, then having them correctly identified as strings is not going to > help much. >
But what is does help is allowing a protocol to be expanded and enhanced while maintaining backward compatibility for both client and server. Provided care is taken to have the protocol contain the previously required items, consumers (clients) can examine the version information and continue based on a minimum required version (i.e., The client *must* be receive version X.Y or higher.) Clients can safely ignore new, unrecognized protocol elements while greatly simplifying server code (which just emits the high-version protocol). I would generally reserve the term "protocol" for wire transmissions (where presumably client and server could negotiate an appropriate version). Many of the self-describing "protocols" you mention become static file formats. This can have its drawbacks. An interesting workaround to this is the use of "critical" key usage extensions in X.509 (forcing the client to reject the certificate if there are key usage restrictions that a specific client cannot recognize). There are also overhead issues (especially for XML). -Piers --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]