This document used to be Appendix A of the Abstract API document in version up to and including 1.2. That was really a historical accident - a hangover from the early days of ZOOM when the whole project was described in the single document that was version 1.0 of the Abstract API. Now I've belatedly removed it into its own document, as I should really have done back in version 1.1.
Although the last few years have seen unprecedented interest in information retrieval, the Z39.50 community has not grown as expected in this time, due to poor take-up of Z39.50 by new programmers. This seems to be largely due to the perception that it is a complex standard and difficult to implement - particularly in comparison with perceived competitors such as HTTP.
In fact, the complexity of Z39.50 is more apparent than real. For example, the standard document itself weighs in well under ten thousand words, of which two thirds make up ASN.1 specification and appendices: in other words, the body of the the standard is only 3300 words long. By contrast, RFC 2616, which specifies the core of HTTP 1.1, is ten thousand words long alone, and is intended to be read along with other specifications such as RFC 2817 (``Upgrading to TLS Within HTTP/1.1''), RFC 2617 (``HTTP Authentication: Basic and Digest Access Authentication'') and RFC 2965 (``HTTP State Management Mechanism'').
Not that HTTP is without its merits. It is an excellent hypertext transfer protocol. It's great for transfering hypertext, which is why it's called HTTP, or HyperText Transfer Protocol. But as we have argued before, it is not a suitable substrate for Z39.50-like information retrieval.
Nevertheless, the wholesale adoption of HTTP for any and every use appears to be pushing the information retrieval community down the technically limiting path of re-implementing Z39.50 over an HTTP substrate, otherwise re-casting Z39.50 as an XML Protocol and generally trying to build some form of ``next generation'' of Z39.50 by changing the bits on the wire.
This is happening largely due to the perception in the wider developer community that Z39.50 is difficult to implement. How has this perception taken hold?
ZOOM attempts to address the first three problems by presenting a much simpler interface to Z39.50 functionality, in the form of a much shorter document (this one), thereby allowing application programmers to ignore the standard document and concentrate on programming their applications. ZOOM cheerfully ignores the last two problems since, despite an honest attempt to understand them, we have no idea what they mean. If anything.
The mysteries of ASN.1 and BER can be completely ignored by application programmers working to the ZOOM interface: the ZOOM implementation takes care of all that.
Isn't that just great?