Why Z39.50 Is Not My Favourite Protocol

2nd April 2003

Some of the bones-headed manoeuvres perpetrated by errant Z39.50 servers:

• 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 USMARC.

• When asked for a record in an unsupported record-syntax, Endeavour will respond with a SUTRS message containing an error message.

• 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
  Connecting...Ok.
  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.)