From: Lennie Stovel Minutes Z39.50 Implementors Working Group Berkeley Conference Center January 31 - February 1, 1991 1) Mark Hinnebusch called the meeting to order and introductions were made. 2) Status Reports a) FCLA - Project funded. Work will be in public domain. Purchased IBM OSI/CS and have it up and running. Doing design work on project now. Hope to start coding in 2 months. b) Thinking Machines/Apple - Have Z39.50 2988 version although not with ASN.1. Hope to get to ASN.1. Will be releasing code to public domain. c) UC Berkeley - Have set up backend DBMS. Working on generalized data description language and getting information for campus information server. Interested in ISODE. d) Apple Advanced Technology - working on Z39.50. Library acting mostly as users and testing efforts of the Advanced Technology group. e) Mead Data Central - doing requirements. Looking to work with corporate partners. f) Penn State - Server ready. No ASN.1 or over TCP yet. Hope to have it in next 6 months. Also have been contacted by Cornell (Project Mandarin) who is interested in doing Z39.50 with Penn State. g) UC DLA - working with Penn State. Also working with UC Berkeley on workstation clients. Also started working with DRA and UC Davis on project to link Melvyl OPAC with DRA circulation information. h) PSI - Have prototype version 2 origin. No user interface yet. Works over ISODE and OSI stack. Interested in TCP. i) Dartmouth - working on campus wide information system. Interested in Z39.50 gateways to other information systems. Looking at ISODE. j) Data Research - Have implemented prototype server using ISODE. Have ported ISODE to VMS. Work is in an evolutionary stage. k) National Library of Canada - Not currently doing very much. Looking at overall OSI status. l) LC - Using OSI/CS and type 1 query in support of LSP project. Working with IBM to fix recursion problem in OSI/CS ASN.1 compiler. m) RLG - Going to use OSI/CS. Currently working on technical architecture. Getting interested in OS/2 platform. First project will be to implement between ILL workstation and mainframe. n) OCLC - Have field test version of CDROM product that will talk Z39.50 to mainframe. Interested in getting Z39.50 over the Internet. Using 1988 version with ASN.1 and translating to internal data format. Giving version of code to Duke and Case Western. o) UCLA - Wants to implement. p) Lawrence Berkeley Labs - Haven't done Z39.50 but do have a client/server access to databases. Interested in keeping an eye on developments. q) Data Retrieval - New to Group. Working on client/server methodology and want to find out more about Z39.50. r) California Department of Water Resources - Tracking standard. Have a lot of information they want to propagate over the Internet. s) NOTIS - Has project going with Indiana and SUNY. Finishing 1st phase specifications. Will use type 1 query but no ASN.1. Will run over TCP. Will address ASN.1 eventually. Initially will have Z39.50 only to other NOTIS sites. 3) Z39.50 Version 2 Draft 2 Denenberg distributed Z39.50 Version 2 Draft 2 and discussed it. He noted that the changes to the ASN.1 and the appendices from draft 1 are not annotated. It was also discovered that ASN.1 in printed copy got mangled and Denenberg will post correct ASN.1 to list. He noted that this draft has considerable changes to the delete service to allow a list of result sets to be deleted. This delete is the US position on what the SR delete services should be but this will need to be argued at international editing meeting. Document was made ZIG 91-001 Michael asked about status of the update service. Denenberg said working hypothesis was it would be a separate standard. It was noted that all ZIGS except ISO and NISO documents are now in Thinking Machines FTP server. Hinnebusch and Denenberg will work on getting regularly updated versions of the ASN.1 from the Z39.50 standard into the FTP server. 4) Maintenance Agency Registration of Implementors Denenberg passed out preliminary list of implementors. List will be maintained by organization not individual so organizations need to designate a contact. To get on list you have to document actual plans to implement Z39.50. Information indicating intention to implement needs to to be supplied to LC and updated annually or organizations will be dropped from list. There is a 6 month initial grace period. Information can be supplied electronically. Denenberg will look into including implementors of SR on list. Document was made ZIG 91-002 5) Application Profile Reaffirmation Denenberg discussed some confusion that existed as to what was agreed to in the Application Profile. Issue of whether we agreed to run Z39.50 with ACSE, Session and Presentation. Denenberg argued that this should be done and asked whether this whole issue needed to be revisited. Issue of what in ACSE and Presentation were useful was discussed. Issue of what in Presentation level needs to be negotiated was discussed. Yeong mentioned that he wants to get agreement to do collaborative work to get Z39.50 over TCP and proposed a restrictive implementation that included full Z39.50 with no other services and no dynamic renegotiation. He believes there is no need for Presentation services except P-Connect and P-Data, and only minimal Session services are needed. Denenberg argued that this could be done in a conforming way as easily. Discussion ensued. Kunze discussed ISODE and its advantages and disadvantages and argued that we need to make a decision soon as to whether we should use it and what parts of it to use - perhaps just use ASN.1 compiler from it. Consensus was that we should do the absolute minimum Presentation and Session that would still interoperate with full blown implementations. Consensus was also that we should go back to the services that are defined in the application profile and the issue is how to get off of the ground and get the code developed that provides those needed services. We agreed to put into the profile what syntaxes are required to be supported. Issue discussed as to whether or not Presentation context add/drop needs to be supported. A suggestion was made to register an abstract syntax that was a transfer syntax called Private - Denenberg will pursue idea. Lynch proposed that initially we assume null Session, Presentation and ACSE just to get application code tested. This would not be a permanent solution but a temporary way of getting off of the ground. He further proposed that 1) we reaffirm the profile as the ultimate goal and 2) we define 2-3 levels of testing that clearly specify what of Session and Presentation was in each level so that we could build up to the full profile definition. There was a lot of agreement with this idea. It was then agreed that Z39.50 on TCP on port 200 will initially: a) Just run APDUs on top of TCP - no ACSE Session or Presentation b) ASN.1/BER would be used c) Z39.50 Bib-1 attribute set and Diagnostic record set would be used. Lynch agreed to spec out what the 2-3 levels that built up to what was defined in the application profile would each contain. The idea is that separate TCP ports would be used for each level. DLA agreed to find TCP ports that could be used for each level. 6) Type 2 Queries Levan brought up issue of Z39.50 type 2 queries using ISO Common Command Language (CCL)and the fact that OCLC adopted NISO CCL. He pointed out problems and ambiguities in the ISO standard. Denenberg pointed out that ISO type 2 queries were in the standard for compatibility with SR and that it was possible to define a new type query that pointed at the NISO standard. There was some sentiment for removing the type 2 query but it was agreed to define a query type above 100 for NISO CCL (Z39.58) 7) ASN.1 Type External RLG distributed a document that described how to treat things in the standard that are defined as ASN.1 type External. It was agreed to discuss this later or on the mailing list. Document became ZIG 91-003 8) Element Sets for Indexes Hinnebusch distributed document containing an element set as an alternative to the full MARC record. This would be a minimal set for public access catalogs for brief displays. The name of the document was thus changed to Brief Display Element Set to make it more meaningful. The document was discussed as to elements included and the use of visible string in the ASN.1 encoding. It was decided to survey major OPACs to see what elements they display in a brief display. It was also decided to add an optional data element that contained anything the server wanted to send and an optional data element called private that would be meaningful between a client and server by outside agreement. It was also stated that this was really a new transfer syntax rather than a new element set. The issue was discussed. Discussion also ensued on the encoding for this. It was decided to register this as a new record syntax called something like Summary. Hinnebusch will revise document to correctly indicate its new purpose. Document became ZIG 91-004 Denenberg mentioned that procedure for registration was not yet completely worked out but that he will work on getting it finalized. A discussion was held over what should be registered and what not and whether or not the registration tree should be distributed. Denenberg proposed a level in the tree for record syntaxes called local and that procedures be developed for allocating pieces of it to organizations. Discussion was held as to whether this should also apply to attribute sets. Denenberg made a tentative decision to subdivide the record syntax tree to allow for the local branch but will think about the implications of this. 9) Record Transfer Syntax for OPACs Hinnebusch distributed a document containing a proposed record transfer syntax for OPACs that includes the MARC record along with holdings and circulation data. FCLA believes that it would be preferable to use the MARC holdings format but recognizes that not many systems support it so they offer an alternative in the document. Hinnebusch also mentioned that this was a first draft put out for review and asked for feedback. DRA agreed to get the preliminary circulation format record from NISO committee LL and Hinnebusch will review it and post it to the list. It was also mentioned that using MARC holdings format would not allow connecting circulation data to individual holdings but that this could be done if ASN.1 definitions were devised for holdings and circulation data. It was also proposed that this document be reviewed by the ILL people. Document became ZIG 91-005 A discussion was then held about what to do about brief holdings records. LeVan proposed a mechanism on present request for passing the actual ASN.1 tag fields to be sent back. This would require an ASN.1 description of the MARC record. This whole issue of should there be an ASN.1 definition of the MARC record and if so what should it look like was discussed. LeVan will come up with a proposal describing this tag passing mechanism on present. 10) Proximity Searching Hinnebusch distributed a document containing an ASN.1 definition for proximity operators. Document became ZIG 91-006 Discussion ensued as to how proximity operators should work and what field definitions applied. Document was modified to include an and proximity operator and an and not proximity operator. Direction was changed to ordered/not ordered. RelationshipDistance was dropped. It was decided that two adjacent words were '1' word apart. It was also decided that left/right ambiguity should be clarified to mean that left is the deeper item on the stack and right is the item on top of the stack. Hinnebusch will repost it to the list with fixes. Denenberg proposed incorporating it in a new type 101 query which makes it a superset of type 1 query. This was agreed to. It was also decided that for now this will not be incorporated in version 2 of Z39.50 but will just be used among the implementors group. Lynch mentioned that the proximity operators creates a need for extensions to diagnostics. LeVan continued to volunteer to work on extending diagnostics and mentioned that he hasn't done anything since last meeting. Denenberg mentioned that new diagnostics can be added to version 2 since they are currently a superset of what is in SR. 11) TESLA at ALA Hinnebusch mentioned TESLA wanted to do a program that showed off Z39.50 at ALA in Atlanta but this was rejected by the program committee due to inability of TESLA to give actual cost figures. He asked what we wanted to be doing about ALA in San Francisco in 1992. Lynch mentioned the possibility of doing a Z39.50 demonstration at Educom as a small trial and mentioned he has suggested it to the Educom program committee. Hinnebusch mentioned that the planned program at ALA would be both a program meeting and a NISO booth with terminals that people could use to search other systems using Z39.50. Michael mentioned the LITA conference in 1992 as another possibility for doing something. Discussion of possibilities ensued. OCLC said they hope to ready to make themselves available as a server for such demonstrations but they are not yet ready to commit to that. Hinnebusch will repose the question of what to do for ALA in San Francisco at the next meeting. 11) Alternative Attribute Set Hinnebusch distributed an alternative to the Bib-1 attribute set and described what he feels are some of the deficiencies in Bib-1, e.g., the inability to do an author search. Denenberg pointed out that Bib-1 already had some of these extensions and that more could be added since US Bib-1 was a superset of SR Bib-1. There was a long discussion about what to do about servers that either did not support certain attributes or remapped them into other things and how the client could become aware of this remapping. Lynch maintained that this problem highlighted the need need for informational messages. This facility could be added in version 3. Denenberg proposed handling this for now in version 2 by using resource control. Discussion was then held on whether using resource control to have the client find out about server remappings would lead to too many resource control messages being sent and whether there should be a facility for the client to indicate up front it was willing to accept any remapping the server wanted to do so as not to get the resource control messages. Lynch asked whether servers would do these remappings dynamically or whether they were a static function of the database. He suggested that if they were static, the information on the remappings belonged in the Explain facility where they could be downloaded to the client. The Explain facility would tell what attributes that server supports or does not support, what attributes are automatically remapped, what are remapped but not well and what attributes are not supported but what alternatives to them exist that the client might try. He also suggested that if there is a need to handle dynamic remapping it could be done with resource control or informatory messages or through a new service but that this still needed to be evaluated. Hinnebusch proposed some additions to the version 2 Bib-1 attribute set from his alternative attribute document. It was agreed to add: Author Personal Author Corporate Author Conference Author Alphanumeric Identifier ChildrensSubjectHeading PersonalNameAsSubjectHeading Hinnebusch will post to list what attributes his system supports and what MARC tags they map to. He suggested other people do the same. Thwaites asked questions about the intended use of certain attributes. Denenberg proposed an information appendix to the standard that would explain what each attribute meant. Dixson agreed to attempt to create this appendix and will post a draft of it to the list for discussion. It was also decided that new attributes can be proposed on the list between meetings but that the actual decisions on which to add will be made at the meetings. 12) Review of Version 2 Draft 2 Having had an opportunity to read the version 2 draft 2 after the 1st day of the meeting some questions and confusions were discussed and some corrections were made. However it was decided to defer informative discussion to the mailing list. Denenberg agreed to organize a technical report on Z39.50 to help explain the protocol and serve as a tutorial on it. 13) OSI IP over the Internet This was deferred. LC will post material on this to the mailing list. 14) Attendees Name Institution Email ---------------- -------------- ------------------ Mark Hinnebusch FCLA FCLMTH@NERVM.Bitnet Sara Randall NOTIS RANDALL@NUACC.Bitnet Allison Woodruff CA Dept Water Resources woodruff@water.ca.gov Gary Darling CA Dept Water Resources gary@water.ca.gov Art Gardner Data Retrieval phone:414-539-1960 Allan Konrad LBL Konrad@cmsa.berkeley.edu Jeff Suttor UCLA ecl4jms@mvs.oac.ucla.edu Ralph LeVan OCLC rrl@rsch.oclc.org Jay Field RLG BR.JWF@RLG.Bitnet Lennie Stovel RLG BL.MDS@RLG.Bitnet Rich Fuchs RLG BR.RBF@RLG.Bitnet Larry Dixson LC bb.shm@rlg.stanford.edu Ray Denenberg LC bb.ray@rlg.stanford.edu James Michael Data Research jim@dranet.dra.com Joe Zeeman Software Kinetics Ltd zeeman@crc.skl.dnd.ca Sean Donelan Data Research sean@dranet.dra.com John Kunze UC Berkeley jak@violet.berkeley.edu Eric Bivona Dartmouth Eric.Bivona@dartmouth.edu Susan Stone UC Berkeley sstone@violet.berkeley.edu Wengyik Yeong PSI yeong@psi.com Cecilia Preston UC Berkeley ceal@asylum.sf.ca.us Clifford Lynch UC DLA CALUR@UCCMVSA.Bitnet Michael Thwaites UC DLA MJTOL@UCCMVSA.Bitnet Margery Tibbetts UC DLA MZTUC@UCCMVSA.Bitnet Ellen England UC DLA EEEOL@UCCMVSA.Bitnet Mark Needleman UC DLA mhn@stubbs.ucop.edu Eric Ferrin Penn State EGF@PSULIAS.Bitnet Peter Ryall Mead Data Central peterr@meaddata.com Janet Vratny-Watts Apple Library watts@apple.com Margaret Baker UC Berkeley margaret@garnet.berkeley.edu Harry Morris Thinking Machines morris@think.com 15) ZIGS The following ZIGs were created at this meeting: ZIG 91-001 - Z39.50 Version 2 Draft 2 (contributed by Denenberg) ZIG 91-002 - Z39.50 List of Implementors (contributed by Denenberg) ZIG 91-003 - ASN.1 External definition clarification (contributed by RLG) ZIG 91-004 - Summary Display Record Transfer Syntax (contributed by Hinnebusch) ZIG 91-005 - Record Transfer Syntax for OPACs (contributed Hinnebusch) ZIG 91-006 - ASN.1 Definition for Proximity Searching (contributed by Hinnebusch) 16) Next Meeting The next meeting will be on May 20-21 at the Library of Congress. The meeting will run from 9AM to 5PM on both days.