Why self describing data formats:

[Bowness, Piers]

> 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 majordomo at metzdowd.com