Why Z39.50 Is Not My Favourite Protocol
2nd April 2003
Some of the bones-headed manoeuvres perpetrated by errant Z39.50
- Many servers ignore the attribute-set ID of queries, assuming
the BIB-1 attribute set.
- When asked for records in a record-syntax other that USMARC,
[Per knows which server] will return a response claiming that
the record is in the requested syntac, but it is actually
- When asked for a record in an unsupported record-syntax,
Endeavour will respond with a SUTRS message containing an
- There are many servers that put useless information in the
AdditionalInformation field, e.g. repeating error messages.
DBC target gives sarcastic comments.
- XXX accepts a referenceId with an INIT request, and then
returns that ID in all subsequent responses, even when
a new referenceId is sent. They treat it as a sessionId.
(Ian will know which server does this.)
- XXX (Per knows) works OK unless you make an Explain request,
after which all records will be returned in NORMARC.
- The Library of Congress (Endeavour) will never report more than
10000 hits however many there really are.
- Then the Washington D.C. Library Consortium server (Voyager
again!) is searched with an access point it doesn't support it
maps the search to the any access point!
$ yaz-client voyager.wrlc.org:7090/VOYAGER
Name : Voyager LMS - Z39.50 Server
Z> find @attr 1=123456789 water
Search was a success.
Number of hits: 10000
- Voyager also runs like a dog - typical times might be five
seconds to handle connection and Init, and another five
seconds to turn around a simple search. (Although fetching
records is surprisingly fast.)
(None of which is really Z39.50's fault, of course.)