From: mhn@stubbs.ucop.edu (Mark H. Needleman)

As promised at the last mtg, here is an updated copy of the
interoperability document with (hopefully) all of the changes we
discussed incoprporated. Send any comments or corrections to me

Mark Needleman

Items for Interoperability Agreements
Last Updated 3/13/92 - Mark Needleman



1) Set protocol version bit 1 for compatability with SR.
   Also set protocol version bit 2 for Z39.50 version 2.
   Bit 2 means version 2 with extentions and agreements
   defined by ZIT

2) Support at least init and search and be prepared to
   accept other pdu's without crashing.

3) agree to try not to send more that 64 byte implementation
   id, name, version, and reference id fields

4) recognize ISO and ANSI OBJECT IDENTIFIERS for attribute sets,
   transfer syntaxes, etc. Agree to send only ANSI OID's.

5) Support record syntaxes SummaryRec and/or US MARC. Optionally
   support OpacRecord and Generic where it makes sense for an
   implementation.

6) support bib-1 attribute set and diagnostic set with
   extentions defined by ZIT.

7) Agree to support type 1 query since it is mandated in the
   standard. Support of all other query types is optional.

8) agree to TCP encoding as defined in Lynch document.

10) recognize F element set name and others as defined in ZIT,
    specifically B for brief.


11) Agree to accept xxdefault (case insensitive) as an
    indication that the client wants or is willing to
    accept whatever the default database is on a server.

12) Agree that if preferred record syntax is specified,
    records will be returned in that syntax or a diagnostic
    will be given if not possible to do so. Server will
    not substitute some other negotiated syntax.

13) Recognize ASN.1 changes as defined by ZIT. Specifically
    this includes:

    a) agree not to reject pdu's with an optional field of
       otherinfo. If present, this will be the last field
       in a pdu and will be encoded as an ANY with a tag of
       [210]

Some other things that that need to be understood about a
server but I dont think we can standardize on are:

a) What actual attributes and combinations of attributes
   are supported and what they mean

b) The names of the databases on the server

c) other record syntaxes it may support beyond the required
   ones. Also other element sets and what they return

d) The contents of the addinfo field of a diagnostic record
   and what it means (possible to standardize this?)

e) For range searching, wether the values specified in the
   ranges are character or numeric

f) Indicate what ZIT ASN.1 extentions are being used.

These are some of the things that a client needs to understand
about a server and are the kinds of things the server should
publish about itself.