Z39.50 IMPLEMENTERS GROUP 8th meeting Library of Congress Washington, DC March 26 - 28, 1992 Attended by: Janet Vratny-Watts Apple Computer watts@apple.com Bob Waldstein AT&T wald@mhuxd.att.com Thorn Roby CARL Systems troby@carl.org Les Wibberley Chemical Abstracts Svc. lhw21@cas.org Willem Scholten Columbia U. Law School willem@lawmail.law.columbia.edu Eric Bivona Dartmouth College eric.bivona@dartmouth.edu Sean Donelan Data Research sean@dra.com Gregory Baber Dow Jones & Co. gregb%warlock@uunet.uu.net Denis Lynch ESL Inc. dml@esl.com Mark Hinnebusch FCLA fclmth@nervm.nerdc.ufl.edu Terry Sullivan FCLA fcltps@nervm.nerdc.ufl.edu Mark Duck Gaylord ducker@galaxy.gaylord.com Brad McLean Gaylord brad@galaxy.gaylord.com Jim Whitmore IBM Kaushi Belani Library of Congress kbel2@rs2.loc.gov Ray Denenberg Library of Congress ray@rden.loc.gov Larry Dixson Library of Congress ldixson@ldix.loc.gov Ralph Orlik Library of Congress rorl@seq1.loc.gov Peter Ryall MDC peterr@meadata.com Tom Owens MIT owens@athena.mit.edu Sara Randall NOTIS Systems Inc. srandall@twain.notis.com Ralph LeVan OCLC rrl@rsch.oclc.org Sylvia Carson Penn. State Univ. msc@psulias.bitnet Eric Ferrin Penn. State Univ. egf@psulias.bitnet Simon Spero Project WAIS ses@cmns.think.com Wayne Davison RLG bb.wed@rlg.stanford.edu Rich Fuchs RLG br.rbf@rlg.stanford.edu Lennie Stovel RLG bl.mds@rlg.stanford.edu Joe Zeeman Software Kinetics zeeman@crc.sofkin.ca John Kunze UC Berkeley jak@violet.berkeley.edu Cliff Lynch UC DLA calur@uccmvsa.ucop.edu Margery Tibbetts UC DLA mztuc@uccvmsa.bitnet Mark Needleman UC DLA mhn@stubbs.ucop.edu Geir Pedersen Univ. of Oslo / geir.pedersen@usit.uio.no Nordic SR-NET Curt Ellmann Univ. of Wisconsin curt.ellmann@ mail.admin.wisc.edu George Watson ZIS watson@zis.ziff.com The group discussed the agenda items in the following order, which is maintained in the notes: A.2. Introductions and status reports B.1. Version 2 status B.3. Proposal to move Version 3 to stabilization B.4. Proposed enhancements list B.5. Version 3 feature description B.8. ZIG profile B.9. Register of implementors B.10. Agreement to use direct reference EXTERNALS only B.11. SummaryRec B.12. Call number in SummaryRec B.15. Adding B element set name B.16. MFHL as choice in OPACRecord B.17. Structured number attribute C.1. Add ErrorInfo to all PDUs C.2. Error PDU D.1. IBM OSI/CS discussion A.6. NIST OSI workshop C.3. ProfileID in InitializeRequest and InitializeResponse C.11. Terminate service C.12. Typing attribute set to operand A.4. Relationship of the ZIG, the ZIT and the Maintenance Agency A.5. ZIG report B.2. ASN.1 bugs in Version 2 B.12. Redefinition of PreferredRecordSyntax C.5. Unsupported attribute set diagnostic C.6. SupportedDiagnosticSets and SupportedResourceReports in InitializeRequest and InitializeResponse PDUs C.7. EXTERNAL DiagnosticRecord C.8. EXTERNAL ResourceReport C.9. EXPLAIN C.4. General purpose attribute set and record syntax, info-1 D.2. Next meeting D.3. Schedule meeting in September time-frame C.10. Object access and processing B.14. Handling unsupported record syntaxes B.5. Version 3 feature description Schedule for upcoming meetings: June 1 - June 3, hosted by NOTIS, Evanston, Illinois. September 23 - September 25, hosted by RLG, Mountain View, California. December 9 - December 11, hosted by FCLA, Gainesville, Florida. March 1993, hosted by CARL, Denver, Colorado. A.2. INTRODUCTIONS AND STATUS REPORTS John Kunze, University of California, Berkeley: Demos of the Z39.50 implementations of Berkeley, UC DLA, and Penn State, are being given at the Net92 conference, concurrent with the ZIG. John will release the source code for his protocol machine (server and client) in the next two weeks. [Done.] Janet Vratny-Watts, Apple Computer: Observing. Eric Bivona, Dartmouth College: Dartmouth's internal CWIS is functioning. Eric will make the WAIS gateway from the CWIS publicly available soon. He has a rudimentary version of his gateway to Version 2 of Z39.50. Greg Baber, Dow Jones: Observing. Dow Jones has a working WAIS implementation running. George Watson, Ziff: George heard about Z39.50 last week. Joe Zeeman, Software Kinetics and National Library of Canada: Software Kinetics hopes to start implementation of a Z39.50 client within the next month. Peter Ryall, Mead Data Central: Peter's designs are finished and he is working on prototyping, including a profile that they are working on with NeXT. He is using John Kunze's generic code. Mead will have a prototype ready by June, and a full implementation of a server and of clients on PC and Unix platforms by the end of the year. Curt Ellmann, University of Wisconsin: A prototype is running and is being migrated to an RS6000; they are planning their implementation. Mark Hinnebusch, Terry Sullivan, FCLA: Terry's client and server can talk to each other but not to external clients or servers yet. They are running over OSI/CS, and they can send session layer buffers over TCP/IP. They are looking at two interfaces, one at the presentation layer, and one at the session layer. Larry Dixson, Ralph Orlik, Ray Denenberg, Kaushi Belani, Library of Congress: They plan to implement Z39.50 over TCP/IP within one year, then to implement it over an OSI stack. Simon Spero, Project WAIS: Simon is working on the next generation of WAIS, which will conform to Version 2 of Z39.50. Code for the basic protocol layer will be available shortly through the University of North Carolina-based WAIS consortium. Geir Pedersen, Nordic SR-NET / University of Oslo: The Nordic SR-NET project is implementing SR over ISODE. The project has participants from the library community in the Nordic countries. The main goals of the project are: 1) To make available a solid implementation of SR on top of ISODE that can be picked up by organizations that want to use SR. 2) To make available a number of Nordic bibliographic databases over SR. 3) To integrate an SR-client into user interfaces of some existing Nordic library systems. The project is scheduled to have completed an implementation of SR by the autumn while the project as such will run until early autumn 1993. In addition to participating in the Nordic SR-NET project, Geir is also working with X.500 for UNINETT, the Norwegian academic computer network. He is also participating in RARE WG3, a European group focusing on directory and information systems. Jim Whitmore, IBM: Jim was attending the meeting to solicit comments and requirements for IBM's OSI products. Sara Randall, NOTIS: NOTIS is working on the BER for a Z39.50 client, which they plan to have ready by early summer, along with a working server. Les Wibberley, Chemical Abstracts Service: Les is building a case within his company for a Z39.50 gateway to the company's STN search service. He is building a prototype WAIS gateway for demonstration, while waiting for management approval. Ralph LeVan, OCLC: Ralph has finished the graphic workstation based on Version 1 and has started coding a server and a rudimentary client that conform to Version 2. He plans to test interoperability with participants in the Coalition for Networked Information (CNI) Z39.50 Interoperability Testbed (ZIT). Bob Waldstein, AT&T Library: Bob has implemented a correct server and two external clients have connected to it. He will distribute his code before June. Sean Donelan, Data Research Associates: Sean has several ASN.1 compilers that work, and he is trying to decide which to use. The Digital OSI product's compiler compiled the ASN.1 for Z39.50 after Sean applied some workarounds. His client uses DRA's ASN.1 code, which he might replace with Digital's. Thorn Roby, CARL Systems: CARL is in the early stages of developing a Tandem-based client and server. Their proprietary environment has hampered development. Rich Fuchs, Lennie Stovel, Wayne Davison, RLG: RLG is making progress though it is still in the same place, trying to connect over TCP/IP. A quick trial of their client with the Melvyl server was partially successful. Rich is working the bugs out of the BER. RLG's forthcoming patron-oriented search service, though a mainframe system, is being designed as a Z39.50 client, leaving open the possibility of running it on another platform in the future. Tom Owens, MIT: MIT is working on a prototype of archives data using WAIS; they are in the process of collecting the data. They expect to roll their own implementation, after agreements with Carnegie Mellon could not be reached. Willem Scholten, Columbia University Law School: The Law School's catalog is on a WAIS server, and they are building a free text search system using WAIS. They are thinking about joint implementation of Z39.50 with the main library at Columbia. Denis Lynch, ESL: They have a government contract for a full text application of Z39.50 for a message-handling system. The contract requires lots of dissemination. Following the introductions, the ZIG commended Mark Hinnebusch for his contributions over the life of the ZIG with a plaque that read "Our appreciation to Mark Hinnebusch for two years of remarkable leadership from the Z39.50 Implementors Group." The accompanying water pistol may or may not have dampened Mark's intended targets. B.1. VERSION 2 STATUS Ray Denenberg reported that NISO had~r received 21 yes votes, 2 yes votes with comments, 6 abstentions, and 2 no votes. No major technical changes have been proposed, and NISO is working to resolve the comments of the negative votes. B.3. PROPOSAL TO MOVE VERSION 3 TO STABILIZATION Mark Hinnebusch asked how the ZIG could help the Maintenance Agency to move Version 3 of the standard to a stable form. In particular, FCLA needs dialog capabilities. Ray suggested that the group return to this question at the end of the meeting, following discussion of proposed enhancements. Concern over going down different paths from ISO SR was expressed. Wayne Davison suggested some criteria for considering a feature for inclusion in Version 3, to keep in mind during the meeting: the work is mature and the feature is of broad interest and applicability. It was observed that no other work on Z39.50 was going on within NISO and that this group contained the implementers of the standard. B.4. PROPOSED ENHANCEMENTS LIST B.5. VERSION 3 FEATURE DESCRIPTION Ray Denenberg distributed three documents: "Z39.50 Maintenance Agency Document List", January 1992 (ZIG 92-005); "Z39.50 Maintenance Agency Proposed Enhancements", March 1998 (ZIG 92-006); and "Z39.50 Version 3: Feature Description", Second Draft, March 1992 (ZIG 92-007). The list of proposed enhancements gives 22 features that have been suggested, together with the name of the person who volunteered to write a proposal for the feature. It also shows whether the feature is intended for Version 3 or Version 4, or whether it is an object that is to be registered. The group made a couple of adjustments to the list. Descriptions of some of the registered items, notably the Explain features, could be published along with Version 3. Ray briefly discussed the source of each of the 14 items in the Feature Description document. Most of the items were discussed at greater length later in the meeting. B.8. ZIG PROFILE Ray Denenberg reminded the group that no institution is implementing the profile that was discussed at the first few ZIG meetings. Z39.50 is in the appendix of the US Government OSI Profile (GOSIP). Ray distributed a "Draft description of information retrieval for GOSIP", January 1992 (ZIG 92-008). In order for Z39.50 to be included in the body of GOSIP, one or more profiles must exist. Jim Whitmore added that if Z39.50 were included in GOSIP with a timetable for vendors, it would get attention from IBM's OSI development group. Ray noted that the Profile Requirements List (PRL), which covers only the Z39.50 protocol, is a subset of the profile, which covers the upper three layers. The ZIT has a document that is essentially a profile. Ray asked people to send him comments on the PRL together with filled in PRLs within six weeks. B.9. REGISTER OF IMPLEMENTORS Ray Denenberg distributed a draft of "Z39.50 Maintenance Agency Z39.50 Register of Implementors", March 1992 (ZIG 92-009). People can send updates to him until May 1. The initial version will be published in June. Thereafter the Maintenance Agency will update it two times a year. B.10. AGREEMENT TO USE DIRECT REFERENCE EXTERNALS ONLY Z39.50 implementations that do not use presentati~ron context negotiation, including those that run over TCP/IP, need to use a direct reference to refer to an EXTERNAL data type. Mark Hinnebusch suggested that the ZIG agree to this convention in general, as opposed to relying on the presentation layer to supply the indirect reference. His implementation will use Explain to find out what object identifiers the server uses. Terry Sullivan advised the group that this aspect of using the presentation layer is relatively simple to implement and provides a presentation context identifier that is shorter than the direct reference. Denis Lynch pointed out that systems using presentation context negotiation still cannot establish a hierarchy of preferred syntaxes. Mark Hinnebusch volunteered to try to define the issues surrounding the use of direct references for EXTERNALs. B.11. SUMMARYREC B.12. CALL NUMBER IN SUMMARYREC Mark Needleman distributed the definition of a summary record (ZIG 92-010). It derived from the brief bibliographic record Mark Hinnebusch had proposed at a previous ZIG meeting. The ZIT had generalized it to apply to other than bibliographic records. Mark had added call number following the ZIT meeting. Mark Hinnebusch will register and post an object identifier for it. Someone suggested that the definition of UserInformation given in ZIG 92-007 be substituted for the otherinfo field. Someone else observed that the type Visible String limited the fields to 7-bit ASCII, that is, these fields can not include diacritics. Wayne Davison said that a new type that might suffice is coming from SC21. He also suggested that format be made optional; the ZIT had intended this. B.15. ADDING B ELEMENT SET NAME Mark Hinnebusch suggested adding "B" as an element set name to Version 3 of the standard and to the ZIG profile. The group agreed. Lennie Stovel distributed copies of the brief element set that RLG will provide when the record syntax is USMARC and the element set is B (ZIG 92-013). B.16. MFHL AS CHOICE IN OPACRECORD Mark Hinnebusch suggested adding the USMARC Format for Holdings Data (referred to as MFHL from its earlier colloquial name, MARC Format for Holdings and Locations) as a choice for holdings information in the definition for an OPACRecord. The group agreed. Mark will register an object identifier for this record syntax. B.17. STRUCTURED NUMBER ATTRIBUTE John Kunze distributed "New Structure Attribute for bib-1: Structured Number" (ZIG 92-011) and explained his requirements for such an attribute. After some discussion, the group felt that the user of such an attribute intends to identify a class or group of objects, possibly based on an alphanumeric code. The attribute will be added as Structure attribute 103 in Version 3 of the standard. A reprise of an earlier discussion of Use attributes for "any" and "default" led to a decision to add both. The Maintenance Agency will assign value 1016 to "any" and 1017 to "default". C.1. ADD ERRORINFO TO ALL PDUS Terry Sullivan withdrew this agenda item after noticing that "error" could be one category of user information as defined in ZIG 92-007. C.2. ERROR PDU Mark Needleman distributed the definition of a PDU for error information (ZIG 92-012). The ZIT had discussed using such a PDU but had decided not to use it within the initial time frame of their agreement. Three organizations--RLG, FCLA, and CAS--expressed interest in using it. Wayne Davison sorted the discussion into three types of proposals for using an error PDU: (1) to send information about an abort (this case is redundant with the purposes of the Association Control Service Element, which the ZIT has agreed not to use); (2) to report an error and leave the protocol in a different defined state; (3) to report an error without changing the state. The group felt that the state that exists after an error PDU should be defined in the standard. They also agreed that clients and servers should not respond to an error PDU with an error PDU. Others suggested that it should be called an exception PDU and that it should contain information about the precipitating event, the date of the event, a reference ID and a dialog ID. Mark Hinnebusch volunteered to draft a more complete statement of the implications of an exception PDU for the state tables. D.1. IBM OSI/CS DISCUSSION Ray Denenberg recounted two early problems with the IBM OSI/CS product: lack of support for recursion in the ASN.1 compiler, and cost. More recently, the lack of context negotiation has surfaced. However, LC still might find it possible to use the output from the ASN.1 compiler to run over TCP/IP to meet ZIT agreements. Ray introduced Jim Whitmore, an IBM employee with responsibilities for technical support for OSI products. Jim outlined his two purposes for coming to the ZIG meeting: he wants to close the loop of communications regarding the functionality of OSI/CS, and he wants to solicit feedback about what IBM can do better in supporting the ZIG. He feels that OSI/CS has about 75% match with the ZIG's requirements, lacking recursion, multiple transfer syntaxes, and the ability to run OSI over TCP at the transport layer. The ZIT's agreement to use direct references gets around the problem of multiple transfer syntaxes for the time being. Recursion has been added because it is needed for supporting X.500; it will be made available to the ZIG. IBM had announced the day before that it will enable disconnecting the application layer from the transport mechanism. Sara Randall observed that people would switch to using all the upper layers if support were available on multiple platforms. Wayne Davison said that people are concerned with space and do not need all of OSI; people should be able to compile a subset. Jim referred to the administrative facility that supports this requirement. Jim said that IBM is working on the cost of the product and on the time it takes to implement. They are trying to put it in the Higher Education Software Consortium[?]. A.6. NIST OSI WORKSHOP Ray Denenberg recommended that the group consider whether becoming a special interest group of the NIST workshop for implementors of OSI would provide significant benefits. He introduced Tim Boland, the chair of the workshop. Tim began by saying that the workshop has changed its name to the Open Systems Environment Workshop, to allow consideration of other public specifications as well as OSI. The workshop was organized in 1983. In the workshop, vendors, users, and suppliers reach implementation agreements on OSI protocols; purchasers can use the agreements as the basis for procurement and testing. Tim outlined three recent trends: (1) more constituencies have expressed interest in interoperability; as a result 14 special interest groups exist; (2) more products are available and the constituencies show increasing concern with testing and therefore need more precise agreements; (3) international harmonization of agreements is increasing (Tim cited the library applications Search and Retrieve and Interlibrary Loan that have come up in Europe). The workshop has stable implementation agreements, working documents, and a procedures manual. It meets four times a year at Gaithersburg, Maryland. At the meetings, an open public session called a Plenary agrees to proposals from the SIGs. The ZIG could ally itself with the workshop in one of three ways: (1) it could replace its current meetings with meetings held during the same week as the workshop, that is, become a SIG; (2) it could assign a subgroup of the ZIG to attend the Plenary; (3) it could assign a subgroup to become a SIG. The advantage to the ZIG would be that our requirements would be in stable documents for all interested constituencies. Ray urged ZIG participants to read the Workshop documents, including the procedures manual that was distributed at the September 1991 ZIG meeting (ZIG 91-030), and to discuss this again at the next ZIG meeting. C.3. PROFILEID IN INITIALIZEREQUEST AND INITIALIZERESPONSE The request to name supported profiles in the Init was withdrawn, since the Association Control Service Element (ACSE) handles this by naming the application context in the Associate Request. C.11. TERMINATE SERVICE The group agreed that we do not need Terminate for Version 2. We postponed the discussion to allow time for other items. C.12. TYING ATTRIBUTE SET TO OPERAND Because we envision having more than one attribute set, we need to be able to associate the attribute set with the term, rather than with the query as a whole. For upward compatibility, we could add an optional attribute set parameter to the AttributesPlusTerm parameter. Mark Hinnebusch will document the ASN.1 changes to accomplish this within the Type 101 query and consider the impacts of this change on diagnostics. Another solution suggested was to create superset attribute sets out of a combination of smaller sets. A.4. RELATIONSHIP OF THE ZIG, THE ZIT AND THE MAINTENANCE AGENCY Clifford Lynch distributed "NISO, the Z39.50 Maintenance Agency, the Z39.50 Implementor's Group, and the Coalition for Network [sic] Information's Z39.50 Interoperability Testbed: Terms of Reference" (ZIG 92-001), characterizing it as a summary of the views of Ray Denenberg, Mark Hinnebusch, and himself. He stressed the short-term nature of the ZIT and the fact that most institutions in the ZIT want to test with any other institution, regardless of ZIT participation. The ZIT does not plan to change the ASN.1 of the standard but will use changes made by the ZIG and the Maintenance Agency. Ray Denenberg suggested that the ZIT should appoint a liaison to represent itself to the ZIG. Lennie Stovel objected, saying that institutions that are interested in the development of the standard should participate in the ZIG directly. Ray Denenberg suggested adding development of profiles as a specific function of the ZIG, separate from enhancing and refining the standard. He will also provide a rewrite of the last paragraph. The ZIT will use its mailing list primarily for administrative mail, occasionally floating items that will then go to the ZIG. Clifford will incorporate changes in the document and post it to the Z3950IW listserv and then send it to Information Standards Quarterly for publication. A.5. ZIT REPORT Clifford reported that the Z39.50 Interoperability Testbed group has a stable set of agreements for implementation. Some of the ZIG's agenda items on record and transfer syntaxes derive from difficulties encountered by the ZIT participants. The ZIT plans to demonstrate at EDUCOM and CAUSE. Its next meeting is scheduled for June 4 in Chicago, immediately following the next ZIG meeting. B.2. ASN.1 BUGS IN VERSION 2 The next five items arose from points identified during the recent ZIT meeting and described in email from Clifford Lynch to the Z3950IW listserv on March 15, 1992. B.13. REDEFINITION OF PREFERREDRECORDSYNTAX Since queries can cover multiple databases, a single preferred record syntax per query might prove insufficient, as the same syntax might not be applicable to all the databases. As this is still a hypothetical case, the group decided it did not warrant changing Version 2 at this point. Mark Hinnebusch will try to identify the issues surrounding this item. C.5. UNSUPPORTED ATTRIBUTE SET DIAGNOSTIC The ZIT sees a need for an error code for unsupported attribute set in queries. Even if users of the presentation layer negotiated the agreed-upon OIDs, a client might still use a direct reference to another attribute set in a query. Ray will add this to Version 2 as condition 121 in the bib-1 diagnostic set. C.6. SUPPORTEDDIAGNOSTICSETS AND SUPPORTEDRESOURCEREPORTS IN INITIALIZEREQUEST AND INITIALIZERESPONSE PDUS Questions arose in the ZIT about what happens when a client receives a diagnostic set or a resource report format that it does not know about. Listing supported diagnostic sets and resource report formats in optional fields in the Init and Init Response PDUs would help avoid this situation. The group agreed to proceed with definition of these fields; Clifford will move them forward. Denis Lynch observed that this is a profiling issue. That is, the profile lists supported sets and formats, and the exchange of ACSE PDUs would establish the profile being used. [Note that this change became unnecessary following discussion of the next item.] C.7. EXTERNAL DIAGNOSTICRECORD C.8. EXTERNAL RESOURCEREPORT Clifford said that defining diagnostic record formats and resource report formats as EXTERNAL and registering the formats would give implementers more flexibility to define formats appropriate to the environment. Terry Sullivan observed that this might preclude the need for listing supported formats in the Init. There followed another discussion of the ways that use of Presentation facilities does and does not support the needs of the ZIG and the ZIT. Ray Denenberg said that making the diagnostic record EXTERNAL will become part of Version 3, since it would disrupt the current correspondence between ISO SR and Z39.50; it will probably be an acceptable revision.~r He will explore whether he can incorporate making resource report EXTERNAL in Version 2, since SR does not have the resource control facility. Clifford will make a proposal to the ZIT for how to handle these aspects in the meantime. C.9. EXPLAIN Clifford Lynch distributed a draft of "EXPLAIN SERVICE FOR Z39.50", 3/20/92 (ZIG 92-002). Joe Zeeman had worked on refining the ASN.1 definitions and volunteered to continue. The paper defines a database with a distinguished name that is available on all servers that support the Explain facility. It describes an attribute set for use with the Explain database and lists the Use attributes together with a set of reserved terms associated with each Use attribute. Use of a particular term in a query would elicit an expected record or set of records in response. The attribute set is a subset of bib-1, containing Use attributes, Relation attributes and Structure attributes. ZIG 92-002 also defines a record syntax to be used when retrieving records from an Explain database. [Note: following the extensive discussion of Explain during the meeting, people continued to suggest additions and changes via the listserv. Joe revised the definition to incorporate all the comments made during the meeting and on the listserv. He included copious notes that describe the need for and meaning of various data elements. These minutes omit the description of the discussion as it has been superseded by Joe's revised document. -- Your lazy minutes-writer, Lennie.] C.4. GENERAL PURPOSE ATTRIBUTE SET AND RECORD SYNTAX, INFO-1 John Kunze distributed a draft of his paper "Non-Bibliographic Applications of Z39.50", 17 March 1992 (ZIG 92-004). It describes a dynamic general purpose attribute set called info-1 that contains both predefined Use attributes and generic Use attributes. It also describes a dynamic general purpose record syntax called info-1 that contains generic element tags and allows for dynamically defined elements. John explained that what the paper describes is a solution to several problems at once; however, a server need not implement all of it at once. The capabilities can be used with Version 2 of Z39.50, however the use of the element set names parameter appears to need more complete description. Several of the implementers agreed they could use this solution. The group discussed the handling of copyright in the info-1 record syntax. Someone suggested adding a Use attribute for "default" to the info-1 attribute set. Clifford urged the use of some very generic least common denominator capabilities for interoperability between campuswide information systems, wide area information servers, and bibliographic and non-bibliographic database servers. [Although it was not discussed during the meeting, John and Margery Tibbetts compared the info-1 and summary record syntaxes, and John added some fields to info-1 to align the two syntaxes more closely. He documented the comparison and the additions in "Mapping Briefbib/Summary Record to Info-1", 3/28/92 (ZIG 92-014).] D.2. NEXT MEETING D.3. SCHEDULE MEETING IN SEPTEMBER TIME-FRAME Schedule for upcoming meetings: June 1 - June 3, hosted by NOTIS, Evanston, Illinois. September 23 - September 25, hosted by RLG, Mountain View, California. December 9 - December 11, hosted by FCLA, Gainesville, Florida. March 1993, hosted by CARL, Denver, Colorado. C.10. OBJECT ACCESS AND PROCESSING Peter Ryall presented and described "Object Access/Processing Service", 3/24/92 (ZIG 92-003), which he wrote based on discussions among himself, Ralph LeVan, and Les Wibberley. The paper provides a framework for operations on various objects used in information retrieval, for example, a search, a result set, or a search profile. Typical operations include save, replace, delete, and list. It is less complex than OSI Object Management (DIS 10164-1) but provides needed facilities because it is tailored for the Z39.50 environment. It defines a set of functions to be performed on an object to make it persistent and to use it once it has been made persistent. The intention is to specify completely the objects and the operations so that common agreement can be reached. People had various specific questions; for example, whether conformance meant you could support all of the objects and functions, and how a query object gets created. The group agreed that sorting was both an "online" and a "batch" function. The remaining discussion centered around how much to carry in a single PDU versus breaking functions or objects into separate PDUs. Peter was encouraged to develop a matrix of object and PDUs, or functions and PDUs, and to provide the assumptions and requirements underlying the service. It is possible that the approach could be incorporated in Version 3 with only some of the functions specified. B.14. HANDLING UNSUPPORTED RECORD SYNTAXES The ZIT has agreed to use the preferred record syntax as a strong statement of what the client needs, and if a server cannot handle that request, it provides a diagnostic rather than a different record syntax. This is at variance with the standard. B.5. VERSION 3 FEATURE DESCRIPTION Ray Denenberg referred back to ZIG 92-007. Section 1 in that paper deals with Close, Suspend, and Resume Dialogue. It addresses three requirements: multiple serial dialogs, multiple concurrent dialogs, and dialogs extended across associations. Joe Zeeman suggested that the ISO work on Extended Application Layer Structure (ISO 9545/DAM 1), which talks about multiple application service objects on an association, might be relevant. People questioned the apparent added complexity of the concept of an implicit initialization of a dialog, even though its use cuts down the number of PDUs. However, the group did not agree whether parameters given in the first initialization could be changed by a subsequent explicit initialization. Ray will continue discussion of this feature in the international arena. Section 6 of ZIG 92-007 is largely drawn from the US comments on the proposed draft amendments to ISO 10162 and 10163 on Browse. The ZIG said this section looks good. Ray gave credit to Liv Holm of Norway for getting the wheel turning on this issue. Section 8 concerns the addition of a User-information parameter to each PDU. After a discussion of the degree of structure needed in this parameter, the group accepted the proposed structure but changed the name of the parameter to Other-information. The Object Access/Processing Service described in the Ryall paper overlaps with Section 3 (Periodic Query Facility) and Section 4 (Save-result-set Service) of ZIG 92-007. Ray agreed that Version 3 should include these two functions and opened the question of which definition to use. Peter agreed to work up specific information on these two functions. How the server communicates the number of result sets it will retain for a client (Section 5) is linked with the handling of dialogs: does the number refer to a single dialog or to an entire association? Therefore this item will be set aside for now. Clifford Lynch will supply a write-up on segmentation (Section 9) for the next version of ZIG 92-007. The remaining sections were discussed very briefly. Ray estimated that he might be able to complete a stable document describing the features to be added to Version 3 of Z39.50 by the September ZIG meeting. Next he will prepare a new draft of the standard itself, possibly before the December meeting. Balloting on Version 3 of the standard could take place in 1993. This depends on getting input from the ZIG. As an alternative, NISO could name a small committee to do the work. Generally people felt that those who know what is needed are in the ZIG, however.