Notes from First Z39.50 Implementors Group Meeting Z39.50 Meeting - Washington 90-03-12 1. Z39.50/ISO SR LSP agreed to implement Z39.50 using ASN.1. Plan to propose changes to Z39.50 to make it compatible with SR. Role of Z39.50 maintenance agency; repository for source code? Mark Hinnebusch to set up Z39.50 list server and possibly a file access capability. Thinking machines: up and running in month or two. Running over TCP/IP, modems, Apple Talk. OCLC: 9 months experience with NYSERNET and ISODE. LC: planning both origin and target for a) - authorities (LC as origin) b) - NCCP (LC as target) using type 1 query. time frame: 1st 6 months of 1991 OSI CS implementation, will be X.25 support only and TCP/IP cutover for LSP to occur after testing of LC-RLG linkage. Digital Equipment Corp. is supporting Penn State & Virginia College. Mercury Project at CMU is Z39.50 and ISODE. OCLC is interested in simplification (e.g. removal of session service) for local use. Oranizations planning to build on the different stacks are: TCP/IP ISO ========= ======== ICS RLG UC/DLA OCLC RLG (also ISO) FCLA Thinking Machines (PC orientation) LC VPI DRA DRA (probably 1st) NLC Dartmouth (PC-orientation) OCLC (also ISO) 2. Profiles: - need 2, one for TCP and one for OSI - Z39.50 PICS proforma: responsibility for PICS - existing LSP PICS: not necessarily in standard form. registration issue: use of the object identifier tags instead of pre-allocated tags. use of Z39.50 vs SR: use ASN.1 and SR version, but include resource control and access control. Issue of acceptability of Z39.50 access control in ISO version, may not sell internationally. More accurately, enhance Z39.50 to achieve interoperability with 10162/3. Will not be backward compatible. Access control to become an addendum to Z39.50. Timing of NISO ballot addendum is within next 6 months. LC is proceeding on the assumption that no significant changes will be made and so is not waiting for standards process to complete. University of California DLA planning to implement resource control. Document Retrieval: special working group to consider special requirements. GOSIP conformance: no issue Z39.50 was not accepted in GOSIP suite initially. Registration: NISO will act as registration authority for ISO SR and Z39.50 registration. Z39.50 particulars: - to what extent can origin & target be blind to each other's queries? - OCLC position is that it is very tough, therefore they used query type 0. - big problem - every database indexes differently - need to know something about other's systems practices - same search to same database will produce different results if indexed differently - useful to exchange info about database, is a future enhancement. - possible use of directory - very difficult problem to describe how a database is indexed - possibility of "explain database and describe structure of information managed by a server. - however, want machine readable version of index info, but very difficult (e.g., management of "stop lists", etc). - broadcast: not an immediate issue - refer forward: Possibility of using directory. Possibility of returning a diagnostic forward with info about other sources as a reasonable short term alternative. - record types: - circulation records - MARC record - holdings records - authority records possiblity of 1 composite record syntax. - need to define & register new record syntaxes. where to register? (SR includes national syntaxes). - ASN.1 representation of MARC: new structure definition or represent as a single character string. - LC is concerned about getting agreement an new syntax description. NISO Z39.50 maintenance agency will keep track of implementor & associated database? ASN.1 abstract syntax for record transfer syntax: advantages: (1) consistent with APDUsyntax (2) MARC not suitable for all types of information. disadvantages: effort in developing agreed syntax possible approach: encode MARC as character string for now. Set up working group to develop ASN.1 abstract syntax as a priority. Consider totality of MARC record family. For non-MARC, use ASN.1. Use "format integration" form of bibliographic MARC. Application-Level Services Directory services: shelve for now FTAM: future consideration Use of ASCE in TCP/IP vs. ACP? Profiles: common upper stack - minimum stack layer 1 - 4: TCP now TP/X.25 now TP4/IP in future as migration from TCP Lower Layer Services - basic Session: BCS - full duplex no mandatory segmentation - Presentation: No X.410 No context management Testing & Code Sharing Languages: C, PL/1, Pascal Many groups in public domain: RLG, LC, FCLA Thinking Machines will have public domain server for Query types 1 and 3, with Mac and/or unix (Sun) targets. They will have documentation on internal operation of the server. people encouraged to distribute design documentation, Mark Hinnebusch to act as clearinghouse. Conformance test suite maintained by maintenance facility - more interoperability testing than conformance - no one official "test centre" - test code as a shareable resource Extensions: - use of SQL for bibliographic search: needs extensions to support text. see FullText SQL? - stateless servers: need to change requirement that Present is mandatory. Also may need to negotiate number of result sets. Do separate searches, initial one is type 3, second one is type 1 using "system control no". - setting limits on use of result sets: notification of automatic deletes (possibility of report result) Next meeting will be Tuesday, June 5. We need to look at addressing, taking into account OSI, & TCP/IP addressing and full text.