Z39.50 Implementors' Group Meeting Stouffer Concourse Hotel St. Louis, Missouri June 4-5, 1990 Final Agenda 1. Name of this Group 2. Status Reports 3. Management of Changes, Protocol Changes 4. PICS Proforma Review and Adoption 5. Profile Review and Adoption 6. Document Numbering Scheme 7. Scheduling/Activation of Subcommittees 8. Network Layer Addressing 9. Diacritics and Alternate Character Sets 10. Images, Graphics, Fonts, Large Data Objects 11. Z39.50 Over SNA LU6.2 12. Revisit Layering Over TCP/IP 13. Explain/Help 14. Document Identifiers 15. Add Number of Result Sets to Init Response PDU 16. Make Present a Separate Service 16a. Various Protocol Enhancements 17. Union Catalog Records 18. Search Values for Language in the Attribute Set 19. New Attributes 20. Extension to Retrieve a Set of Attribute Values 21. Stoplists 22. Review Attribute and Error Message Sets 23. Resource Control Request Records Standardization/Registration 24. Testing and Implementation 25. Availability of Code (Code Sharing) 26. ACM SIGCOM 27. Changes to Protocol 28. Revisit ZIG 90-007 and Other Issues 1. Name of the Group The name of the group will be the "Z39.50 Implementors' Group". 2. Status Reports (Highlights) Florida Center for Library Automation They will be acquiring the IBM OSI/CS product before the end of June. They are now reading the manuals. University of California/Penn State University In the design phase of their joint project. Coding will begin in "a month or two." University of California, Berkeley They are working with Thinking Machines on full-text retrieval project. It is anticipated that coding will be completed by the end of summer (1990) = full-text search and retrieval over TCP/IP. OCLC (Ralph LeVan) OCLC is going to send a copy of their Z39.50 software to the National Library of Canada (in approximately 6 months), the University of California, and Penn State (see Press Release attached). Ralph stated that their Z39.50 implementation (a Z39.50 variant) would be available for testing (as a Target) by the 4th quarter of 1990 (over OSI stack). They hope to also be available for testing with their TCP/IP stack at the same time. [Aside: OCLC supports a Type 0 query, but Ralph stated (in the Airport) that he thought that he could also support the Type 1 query (no date). Of course, any bibliographic records retrieved would be ASN.1 until OCLC makes NCCP modifications.] Thinking Machines Z39.50 working implementation by late summer (over TCP/IP). Their partners in this project are Dow Jones and Apple [I don't fully understand how Berkeley fits in]. Part of their code is pure Z39.50; part is for Type 3 query. They have not described in ASN.1. Franklin asked if ASN.1 compilers were available. Virginia Tech In design stage. In 30-45 days working model will be completed at high level. National Library of Canada Doing feasibility study with UTLAS, which will be completed in July. Results will be made available to the Z39.50 Implementors' Group. They will be receiving Z39.50 software from Canada in approximately 6 months. UTLAS Will implement Z39.50 as a Target only. They are not planning to implement as an Origin (at least not for now). NOTIS They are planning to implement a "Z39.50 entry way" during the next two years. For now, they will be controlling both sides of the communication (i.e., Origin and Target). Over TCP/IP. Most of the participants stated that they should have something implemented in 12-24 months. Lennie Stovel mentioned that LITA (at ALA) would be discussing Z39.50 implementations and the Internet. (June 25, 1990, 9:00-11:00) 6. Document Numbering Scheme Documents will be numbered as follows: ZIG 90-001 Documents containing descriptions of implemented variances to the protocol will be numbered as follows: ZIGE-1 ("E" as in "experimental") Documents will be available electronically. (Thinking Machines will set this up.) Instructions on how to access these documents will be posted to Z39.50 email network. Mark Hinnebusch will assign both types of numbers. 4. PICS Proforma Review Dennis MacKinnon had a number of comments (see ZIG 90-008) as did others. The group went through the document page by page. Changes are noted below. Section 6.1: Note what version 2 is likely to include. Section 6.2: It was proposed that we drop "Types 2 and 3" and state "Other types". Section 6.4: Suggested listing other syntaxes. Dennis will supply text. Section 6.6: Change "Pro" column to "o". USMARC is not mandatory. Section 6.7: "Appendix D" will be replaced by SR equivalent. Ralph is going to head an interest group on diagnostic codes, and will collect suggested additions to the list. Lennie proposed adding a number of the "S3" variants as separate diagnostics. Additions will be sent to Ralph and he will edit and send on to Ray [though once they are posted in the network, everybody will have]. We agreed that we should not form subgroups. Take care of interest group topics by sharing ideas in the network. The interest groups will each have a discussion "provoker". For example, Ralph will provoke diagnostics discussion, etc. Section 7.1.1: Change "Pro" column to "ns" for both Max-message and Max-record size. Section 7.1.2: The values "F" and "B" are also possible in the "Simple form", therefore, revise text to clarify this point. Section 7.2: Change "Pro" column to "o" for Delete, Access-Cntrl-Resp, and Rsrc-Cntrl-Resp. Ray will fill out PDUs for Delete, Access Control, and Resource Control in PICS. Section 7.3.3: Change "Pro" column to "o" for MedStElemSetNms and PrefSyntax. Section 7.3.3.1: Change "Pro" column to "o" for named resultSetName xmitted. Section 7.3.3.2: In "Pro" column change "na's" to "o's". Section 7.3.7: "Pro" column = "o", "m", "o". Section 7.3.13: Section was suggested to contain "constraints on User Info Field. After discussion, it was felt that a better place was in the Init APDU and in the Init Response. In Origin Transmission of Init, this would be expressed as "uses" of user information field. In Origin Receipt of Init Response, this would be expressed as "constraints" on user information field. Section 8.1.1: Change "Pro" column values to "ns". Section 8.1.2: Add "Other" values of ElementSetNames. Section 8.2: Change "Pro" column to "o" for Delete, Access-Cntrl-Resp and Rsrc-Cntrl-Resp. Section 8.3.3: Change "Pro" column values to "ns". Section 8.3.3.2: Change "Std" column and "Pro" column as follows: Std Pro names resultSetNames supported o o max concurrent result sets ns ns result sets not unilaterally o o Section 8.3.3.3: Change "Pro" column values from "na" to "o" Section 8.3.3.4: Add "Other". Section 8.3.4.1: Change "Pro" column values to "ns". Section 9: Will contain Vendor Notes. Section 10: Will contain Site Specific Information. Ray will make changes and distribute via electronic mail. 5. Profile Document (ZIG 90-001) Review There was some discussion about a possible extension to the standard. There was interest (Dennis MacKinnon) in having Target transmit end-of-session information when session is terminated. This information would include resource control type information. Ralph LeVan stated that he would rather have information at any time, not just at end of session. Section 8.6: Delete. Considered redundant. Document adopted as edited. 3. Management of Profile Changes, Protocol Changes There is a desire to "fixing" a "Version 2" in time and distributing it. This would perhaps include some of the changes that the group wants. After discussion it was agreed that some "experimental" implementations would precede the standard. They should be distributed (posted) as ZIGEs. The FTP server would be the holder of the "experimental" standard. Consider Option bit assignments (additional "experimental" ones) to be temporary. There is a desire to add some attributes to the Bib-1 list. 9. Diacritics and Alternate Character Sets 10. a. b. and c. Images, graphics, fonts 11. Z39.50 over SNA LU6.2 Mark requested that these be removed from the agenda (since they were his suggestions, and time was in short supply). Nobody objected. 7. Standing Committees We agreed that we should not form subgroups. Interest group topics would be discussed by sharing ideas in the general Z39.50 network. The interest groups will each have a discussion "provoker". I. Diagnostics (additional) -- Ralph LeVan (OCLC) II. Database Records (e.g., bibliographic, holdings, circulation, text files, etc.) This "interest group" will be in two parts: 1. Every type of record except full-text -- Mark Hinnebusch (Florida) 2. Full-text -- Franklin Davis (Thinking Machines) III. Large data objects -- Clifford Lynch (ZIG 90-007) IV. Additional search attributes -- Clifford Lynch 8. Network Layer Addressing Ray distributed ZIG 90-006 and explained concept. No significant discussion. 10.d. Large Data Objects Carnegie-Mellon must transfer several megabytes of data in one record (graphic data). If transferred as one record, they have been having performance problems on busy network (TCP level errors, e.g., having segments retransmitted, throwing packets away, etc.). They wanted flow control at Applications Layer. Now, they use Maximum-message size as fragment indicator. In addition, they are using element set name in "creative" ways. Clifford Lynch distributed ZIG 90-007. He will be the Provoker of ZIG 90-007-related discussion. It was suggested that the Help/Explain could be used to communicate some of this information. Discussion will continue via email with ZIG 90-007 as starting point. 12. Revisit Layering Over TCP/IP Should TP0 be inserted (a general proposal in Internet). It was decided that there was no advantage to adding TP0 under OSI Session, Presentation, and Application. 13. Explain/help Service ZIG 90-009 was distributed by Clifford Lynch. Clifford wants feedback on the document. (Possible expansion, etc.) 14. Document Identifiers We will continue discussion on electronic mail. 15. Add Number of Result Sets in Init Response PDU. It will be recommended to maintenance agency that a field be added to Init PDU that specifies the number of result sets supported by Target. When is a Target considered stateless? = if zero result sets are saved and Present is not supported. The majority of those present felt that it should be possible to not support Present Service. Franklin Davis (with some help from his friends) will prepare a case for a protocol change making it possible to have stateless machines and submit it to maintenance agency. It was agreed that the Init Response was the best place for this information. Many want to be able to state that their system cannot guarantee that any result sets will be saved (i.e., a value equal to "indeterminate" or unknown). It was proposed that this could be assumed if the element value was not included. Stateless = 0 result sets saved plus Present Service is not supported. This will require new text on page 9 of Z39.50 (conformance). There are two issues: 1. Protocol mechanism needed for statelessness 2. The conformance issue Franklin will put together a ZIGE and distribute (post) it. 16. Make Present a Separate Service Clifford asked our forgiveness. No discussion was necessary. 16.a. Various Protocol Enhancements Thinking Machines' Type 3/Relevance Feedback query (related works as search terms). Two types: 1. Related works as search term (document ID included in search term) 2. Keywords are weighted terms present in the text of the documents, but are NOT specified in search term. It was suggested that attributes be added, if possible, to type 1 query to cover these requirements. ZIGE 1 -- Number of Result Sets supported in Init Response ZIGE 2 -- Attribute Extensions needed for Relevance Feedback Query (and other attribute extensions) OCLC would like to include an attribute for browse. It was stated that TC46 folks have been assigned to work on this. When a draft comes out of TC46, it will be distributed (as a ZIG). OCLC would like to be able to request a "human formatted record" (meaning nonstandard, only understood by a human being, not a machine). This record would be a printable string that would be displayed as received. It was suggested that record could be described as printable string with understanding that each sequence is displayed as a separate line (a temporary format type). These would be used if Origin system cannot process Target system records. Some present suggested that a value be added to indicate preferred record syntax. 17. Union Catalog Records Clifford stated that he was simply interested in hearing what types of records libraries were going to be putting in the result sets. Lennie stated that RLIN was NOT going to send primary cluster record only, but will send the entire cluster. The holdings will be embedded in each record. Ralph (OCLC) stated that their holdings database was separate. If searching OCLC, holdings for a particular record can be retrieved by sending a search for a particular record "AND OCLC_Holdings_Database" (i.e., include database_name for the holdings file). This discussion will be continued in electronic mail. 18. Search Values for Language Clifford stated that some systems do not use the USMARC language codes. However, after discussion, it was thought that most systems would carry the USMARC language codes in the 008 field. When an external list is used (e.g., USMARC Language Codes), this information should be generally available. 19. New Search Attributes What is the "scope" of Bib-1 attribute list? Is there a statement? What does bibliographic database mean? Can Bib-1 be used to search other database types? [Some questions that were asked.] OCLC is interested in doing Patent Database searches using Bib-1 attributes, but they feel that they would need to add "inventor", which they feel is different than "personal name". Thinking Machines' attributes could be added (e.g., "score" or "relevance" = how well did document match the query). Discussion will continue over electronic mail. Clifford Lynch with be the Provoker. There was some discussion on the topic of brief records. Dennis MacKinnon does not want brief records to be transferred in USMARC, but wants to use another transfer syntax. He said that he would be distributing a description of the brief record they wish to use in ILL as an example. 24. Testing OCLC -- Ready during 4th quarter of 1990 (OSI stack) Hope to be ready with TCP/IP by 4th quarter as well. Version = variant of Z39.50. Thinking Machines -- End of summer (TCP/IP). Version = Z39.50 (not using ASN.1 initially). Carnegie-Mellon -- End of year (TCP/IP). Penn State/Univ. of Calif -- 1st quarter of next year (TCP/IP). NEXT MEETING The next meeting will be in Washington, D.C. The meeting following that will be on the West Coast. The date of the next meeting was tentatively set for September 13 and 14 (Thursday and Friday). ZIG Document List ZIG 90-001 Application Profile for Z39.50 ZIG 90-002 Profile PICS Proforma for Z39.50 ZIG 90-003 Z39.50 Maintenance Agency : Terms of Reference and Procedures ZIG 90-004 Search and Retrieve Service Definition (ISO/DIS 10162) ZIG 90-005 Search and Retrieve Protocol Specification (ISO/DIS 10163) ZIG 90-006 Addressing Requirements (Network Layer) ZIG 90-007 Image and Full-Text Transfer Under Z39.50 -- Issues for Discussion ZIG 90-008 [Software Kinetics Miscellaneous Comments -- 5 documents] ZIG 90-009 Extensions to ISO DP 10162/10163 to Support an Explain Service ZIGE Documents (not yet distributed) ZIGE 1 -- Number of Result Sets supported in Init Response ZIGE 2 -- Attribute Extensions needed for Relevance Feedback Query (and other attribute extensions)