Z39.50 IMPLEMENTERS GROUP 9th meeting NOTIS Systems Inc. Evanston, IL June 1 - 3, 1992 Attended by: Janet Vratny-Watts Apple Library watts@apple.com Kazu Yanagihara Apple Computer kazu@apple.com Bob Waldstein AT&T wald@mhuxd.att.com Les Wibberley Chemical Abstracts Svc. lhw21@cas.org Julie Mills CIA/U.S. Government Eric Bivona Dartmouth College eric.bivona@dartmouth.edu Sean Donelan Data Research sean@dra.com James Michael Data Research Denis Lynch ESL Inc. dml@esl.com Mark Hinnebusch FCLA fclmth@nervm.nerdc.ufl.edu Terry Sullivan FCLA fcltps@nervm.nerdc.ufl.edu Pat Ensor Indiana State U. libple@indst.indstate.edu Ray Denenberg Library of Congress ray@rden.loc.gov Ralph Orlik Library of Congress rorl@seq1.loc.gov Peter Ryall MDC peterr@meadata.com Bill Cattey MIT wdc@mit.edu Jeff Graubart-Lev. NOTIS Systems Inc. Sara Randall NOTIS Systems Inc. srandall@twain.notis.com Ralph LeVan OCLC rrl@rsch.oclc.org Eric Ferrin Penn. State Univ. egf@psulias.bitnet Rich Fuchs RLG br.rbf@rlg.stanford.edu Lennie Stovel RLG bl.mds@rlg.stanford.edu Joe Zeeman Software Kinetics zeeman@crc.sofkin.ca Harold Finkbeiner Stanford University Harold@forsythe.stanford.edu John Kunze UC Berkeley jak@violet.berkeley.edu Cecilia Preston UC Berkeley cpraeston@info.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 Curt Ellmann Univ of Wisconsin curt.ellmann@ mail.admin.wisc.edu Todd Perry VTLS, Inc. Cathy Winfrey VTLS, Inc. The final agenda for the meeting was as follows. Changes in the agenda are noted in the minutes which follow. 1. Register of Implementors -- MA-023 (Denenberg) 2. Registration of Object Identifiers -- MA-024 (Denenberg) 3. Version 3 survey -- MA-025 (Denenberg) 4. Z39.50 Implementors Group Profile -- MA-026 (Denenberg) 5. MaximumRecordSize=0 or -1 for unlimited (Waldstein) 6. Proximity (Zeeman) 7. EXPLAIN (Kunze) 8. AlternateName and GenericName in EXPLAIN/perFieldDetails (Waldstein) 9. display instructions in EXPLAIN (Waldstein) 10. Dialogues (Sullivan) 11. IR-Object-Access-Facility (Ryall) 12. Info-1 (Kunze) 13. Sort (Stovel) 14. Resource Control and Cost Limits (Denenberg) 15. Fragmentation of data fields (Kunze) 16. Access to generic databases (Kunze) 17. Variant records (e.g., document types) (Kunze) 18. Preferences and defaults for Z39.50 parameters: syntaxes, element sets, attributes, variants, etc. (Kunze) 19. Compiler-friendly ASN.1 coding guidelines (Kunze) 20. Information processing specifications (Kunze) 21. version 2 status report and discussion of proposed late changes (Denenberg) 22. version 3 feature description (V3D3) -- MA-021 (Denenberg) 23. proposed enhancements -- MA-022 (Denenberg) 24. phonetic search (Waldstein) 25. stem search (Waldstein) 26. multiple preferred record syntax (Waldstein) 27. limits on USE attrbiute (Waldstein) 28. Change of meeting frequency (Hinnebusch) Introductions and Status Reports ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sean Donelan, Data Research: DRA has completely reworked their Z39.50 code, using DEC ASN.1/BER products in place of ISODE. The DEC compiler takes a different approach than ISODE, allowing the application to create PDUs element by element, rather than in one call. This change impacted the code logic. Bob Waldstein, AT&T: AT&T has established two Z39.50 servers (targets), one internal, and one external. 100 databases are available on the internal server. Two clients (origins) have been developed, one window-based. Next step is to implement Explain. This will be provided for production use soon. AT&T will also have a server running over Datakit soon. John Kunze, UC Berkeley: Expects to put out a new beta release of Z39.50 software in about a month. The dependency on ISODE has been narrowed down to about three modules, which will be packaged with the next Z39.50 release. Implementation supports multiple records, boolean operators. Info-1 not implemented yet. Harold Finkbeiner, Stanford University: Has developed Z39.50 client code, based on the UC Berkeley code, and has interoperated with the Berkeley server. The client has been incorporated in the Stanford CWIS (Campus Wide Information System). Looking at building a server next. Janet Vratny-Watts, Apple Library: Apple is still in a research stage. Eric Bivona, Dartmouth College: Dartmouth now has a both Z39.50 and WAIS gateways to its CWIS. Todd Perry, Cathy Winfrey VTLS, Inc.: working on a client and server. Bill Cattey, MIT: MIT has the UC Berkeley code running on VAX and RS-6000 platforms, and plan to hook it to BRS server. Sara Randall, NOTIS Systems Inc.: currently testing client, and have successfully communicated with the AT&T target. They will have a target ready for testing in a few weeks. Mark Hinnebusch, Terry Sullivan, FCLA: running client & server over OSI; will be running over TCP/IP on a RS-6000 connected to a production system in about 1-2 months. Joe Zeeman, Software Kinetics: will be starting a client in about 3 weeks. Another organization is developing the server. A National Library of Canada implementation will be available in about 3 months, running over TCP/IP. Lennie Stovel, RLG: currently working through some TCP/IP bugs. Ray Denenberg, Library of Congress: implementation plan has switched to running over TCP/IP. Using DLA encode/decode software. Will have a client up around September for testing. Peter Ryall, MDC: A new company unit has been formed for MDC's Z39.50 service, due to the new wholesale business model it sill support. Contracts are being renegotiated for new business arangements with partners. Working with Apple Computer and NeXT to implement clients. Ralph LeVan, OCLC: Z39.50 server is running on RS-6000 platform, with a client running on a PC for testing. These executables will be available for purchase by early 1993. OCLC will be selling a client API to a local systems vendor. Expect the EPIC databases to be available via Z39.50 by early 1993. OCLC's BER encode/decode software is available via anonymous ftp. OCLC is enhancing this software to support indeterminate length. OCLC will be selling a package including the First Search frontend, the Newton search engine, and a Z39.50 server. Indirect Status Reports for related efforts and missing parties ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~ WAIS: Simon Spiro is working on a database project at Bath, U.K., which will include developing a new WAIS with Z39.50 V2 compatibility and full MARC support. CD ROM: Ralph Le Van has been talking with the folks working on a NISO CD ROM standard. They're apparently re-inventing the SR wheel by duplicating Z39.50 functionality in their standard. Mitch Kapor mentioned WAIS, Z39.50, and SR as important at a recent keynote address. NeXT: Z39.50 is now officially on their feature list, but did not make it into their V3 release. Australia is expressing interest in Z39.50 but is just getting started. Z39.50/SR Seminar in Bath: Cliff Lynch, Ray Denenberg, Sara Randall, Jim Michaels, and others spoke at a Z39.50/SR Seminar in Bath. The purpose of the seminar was to raise the awareness and interest of organizations in the U.K., and to motivate formation of an implementor's group. Clifford expressed the usefulness of keeping in touch with the USA, by establishing a liaison with the ZIG. It was not clear whether organizations in the U.K will implement Z39.50 or SR. ZIG members addressed concerns over the differences between Z39.50 and SR by pointing out that Z39.50 is the same as SR except for two additional features. There were similar concerns over use of TCP/IP vs. OSI (preference for OSI in U.K). The politics are complex. Many European countries (Sweden, Germany, U.K. Norway, Denmark) are currently implementing SR and/or Z39.50 in separate projects, but are not coordinating their efforts yet. Sweden has a project to implement Z39.50 using ISODE over TCP/IP. ZIG Interoperability Matrix ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following matrix was constructed illustrating Z39.50 Interoperability accomplished between Implementors as of the meeting. | | Clients | |Servers|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | |U.C.|Penn|UCB|AT&T|DRA|RLG|NOTIS|MIT|Stanf|Dartm|OCLC|Gaylo|WAIS| |~~~~~~~|~~~~|~~~~|~~~|~~~~|~~~|~~~|~~~~~|~~~|~~~~~|~~~~~|~~~~|~~~~~|~~~~| | | | | | | | | | | | | | | | |U.C. |ISP |ISP |ISP|ISP |ISP|I | I |ISP| ISP | ISP | | | | |~~~~~~~|~~~~|~~~~|~~~|~~~~|~~~|~~~|~~~~~|~~~|~~~~~|~~~~~|~~~~|~~~~~|~~~~| |PennSt.|ISP |ISP |ISP| |ISP| | | | ISP | ISP | | | | |~~~~~~~|~~~~|~~~~|~~~|~~~~|~~~|~~~|~~~~~|~~~|~~~~~|~~~~~|~~~~|~~~~~|~~~~| |UCB |ISP |ISP |ISP|ISP |ISP| | |ISP| ISP | ISP | ISP| ISP | IS | |~~~~~~~|~~~~|~~~~|~~~|~~~~|~~~|~~~|~~~~~|~~~|~~~~~|~~~~~|~~~~|~~~~~|~~~~| |AT&T |ISP |? |ISP|ISP |ISP| | ISP |ISP| ISP | ISP | | | ? | |~~~~~~~|~~~~|~~~~|~~~|~~~~|~~~|~~~|~~~~~|~~~|~~~~~|~~~~~|~~~~|~~~~~|~~~~| |DRA | | | | |ISP| | | | | | | | | |~~~~~~~|~~~~|~~~~|~~~|~~~~|~~~|~~~|~~~~~|~~~|~~~~~|~~~~~|~~~~|~~~~~|~~~~| |RLG | | | | | |I | | | | | | | | |~~~~~~~|~~~~|~~~~|~~~|~~~~|~~~|~~~|~~~~~|~~~|~~~~~|~~~~~|~~~~|~~~~~|~~~~| |MIT | | | | | | | |ISP| | | | | | |~~~~~~~|~~~~|~~~~|~~~|~~~~|~~~|~~~|~~~~~|~~~|~~~~~|~~~~~|~~~~|~~~~~|~~~~| |OCLC | | |ISP| | | | ISP | | | | | | | |~~~~~~~|~~~~|~~~~|~~~|~~~~|~~~|~~~|~~~~~|~~~|~~~~~|~~~~~|~~~~|~~~~~|~~~~| |Gaylord| | |I | | | | | | | | | | | | | | | | | | | | | | | | | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Key: I = Initialize S = Search P = Present Part 2 of minutes June 1 1. Register of Implementors -- MA-023 (Denenberg) ~~~~~~~~~~~~~~~~~~~~~~~~ The first official version of the Z39.50 Maintenance Agency Register of Implementors is dated June, 1992, and is document MA-023. It was distributed at the meeting. It includes a new column "Id", to be used for registration of local objects. This doc will be kept up to date as new implementors come in. Updates should be emailed to Ray Denenberg. Every 6 months a new version will be mailed out. Every 12 months, everyone must renew their registration. Simon Spiro is added as #22 (WAIS implementation). This document was assigned ZIG92-028. 2. Registration of Object Identifiers -- MA-024 (Denenberg) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Procedures for this are described in the document "Registration of Z39.50 OSI Object Identifiers", MA-024. There was discussion of whether "OSI" should be included in the title of "Registration of Z39.50 OSI Object Identifiers". Ray objected to deleting OSI, and noted that he had not received any comments on the document by the deadline. When the document next comes up for revision, deleting OSI from the title will be considered. This document was assigned ZIG92-029. 3. Version 3 survey -- MA-025 (Denenberg) ~~~~~~~~~~~~~~~~ The maintenance agency will conduct a survey among companies who plan to implement or use Z39.50, to determine the relative importance of proposed features and begin the process of narrowing the list of version 3 features to a manageable set. A draft of the survey was distributed (via email) prior to the meeting for review. There was strong support for the process, and few substantive comments on the content of the survey. It was suggested that the preface should indicate some expected time-line, such as "the ZIG wants a ballotable version 3 by June 1993 (or stable by January 1993)". The following issues and suggestions were discussed: Issue: Survey questionaire is planned for dissemination to much wider audience than just the ZIG. If companies are concerned about disclosure of unannounced work, Ray can take private information and incorporate it as an anonymous data set. Individual companies can decide whether or not to disclose their responses (e.g., post to the ZIG listserver). Issue: A particular company may be identified as a very important player and that could result in other members voting in favor of a single feature in order to bring the single important company aboard. Issue: The target date for a ballotable version 3 is June 1993. Many organizations need many of the V3 features IN PRODUCTION by January. Another target date was added: Stable V3 draft by January 1993. Suggestions: Add question for specifying "Push this into Version 4." Add Object Access to the survey. Add question: Importance of compatibility with SR. Add priority ordering for features. 4. Z39.50 Implementors Group Profile -- MA-026 (Denenberg) 4.1 TC 46 ~~~~~ Ray reviewed developments at the TC46 meeting held the end of April. Batch/Suspend/Resume -- Three features were discussed. Batch would allow submission of multiple requests by the client, but has been dropped. It can be satisfied by the remaining two features (Concurrent Dialogs and Suspend/Resume), which continue to be developed. Canada's Concurrent Dialog requirements are different from those of the US Concurrent Operations. It was suggested that the "dialog" term be dropped, and replaced by "Z39.50 Association." Explain -- Will be covered later in the agenda (under EXPLAIN). Browse -- (Renamed to Scan) There were lots of comments from several countries. The majority of the U.S. comments were accepted, and Liv Holm agreed to factor the comments into a new draft. Browsing result sets has been removed from the proposal. The new draft is now available, and will be provided to the ZIG. Access Control/Resource Control/Cost Limit -- access control and resource control had been introduced as amendments to SR. They were reasonably well received. However, one feature perceived to be missing from resource control is the ability for an origin to specify a "cost limit". The agreement in TC46 was that a "cost limit" parameter would be put in existing services. If it occurred in the Init, it would indicate a cost limit for the entire association; if it occurred in a Search, it would indicate a limit for that search; etc. And if it occurred, the target would be obliged to either (a) not process the command because it does not support cost-limits, (b) terminate the operation upon reaching (or approaching, or exceeding) the limit. A flag might be included in which the origin indicates that it doesn't really want the operation terminated, but wants resource-control invoked when the limit is approached. Germany had proposed a NWI to do a Close, instead of the Release. Since Access Control accomplishes what they wanted, the NWI was withdrawn. Proximity -- There was adamant opposition to defining proximity between result sets. 5. MaximumRecordSize=0 or -1 for unlimited (Waldstein) ~~~~~~~~~~~~~~~~~ Indeterminate Maximum Record size: There are some situations where it doesn't make sense to specify or report the maximum record size. Since PDU's are currently not fragmentable, record size is bounded by PDU size. The assumption has been that buffer sizes were fixed and that the record size was determined by it. But now we're serving up bit images of multi-megabytes without buffering. The issue is whether and how to designate a special value of the parameter preferred-message-size to indicate "indeterminate". Proposal: Add a new value of "indeterminate" to be offered by origin or target as the Maximum Record size. Discussion/Issues: Is maximum record size a Database rather than an association level negotiation? Fragmentation may lead to issues in specifying the record size, but we're really talking about maximum record size as it spans PDU's. It was noted that the Maximum Record Size is not currently limited by the Preferred Message Size. If the client asks for a certain size, the server should try to provide it. If the client asks for indeterminate, the server could respond with a specific maximum size, if it can't support indeterminate. If the server specifies a size too big, the client can always terminate. (Server has final say in the Maximum record size spec.) Are there other maximums reported via Explain that we will need to have an "I don't know" value for? Resolution: Specifying an indeterminate size might be useful, but we should codify the procedures. Bob Waldstein (AT&T) will write a proposal for how negotiation would be conducted. 10. Dialogues (Sullivan) ~~~~~~~~~ Terry Sullivan (FCLA) submitted a new proposal (ZIG92-031) which separates concurrent operations from dialogues. This is a middle ground between the extremes of no support for concurrent operations versus full dialogs. This proposal for concurrent operations satisfies Canada's previous Batch requirements. Discussion: There was much discussion on the needs and relative merits of using a single association to service multiple users, versus multiple associations, depending on environment and application: o Acting as a proxy to another server. o Acting as a middle man re-distributing services. o Concurrent searches from one user with multiple windows open Adding Concurrent Operations seems to make multiplexing simpler and cleaner. Cliff Lynch suggested that support for multiplexing dialogues and concurrent operations could be developed as a separate ASE. This would have different implications for running Z39.50 over TCP/IP vs. OSI. However, that possibility may be considered further. Resolution: Among the category of functions which comprised Batch, Dialogues, Concurrent operations, terminate, and Suspend/resume, it was determined that only Concurrent Operations is currently seen as a critical (i.e. version 3) requirement. Thus Batch, Dialogues, Terminate, and Suspend/resume will be deferred to a later version. The FCLA proposal by Terry Sullivan for concurrent operations was well-received, and will be re-drafted by Sullivan, Zeeman, and Denenberg. 11. IR-Object-Access-Facility (Ryall) ~~~~~~~~~~~~~~~~~~~~~~~~~ Peter Ryall (MDC) submitted a new IR-Object-Access-Facility proposal (ZIG92-032). The class of functions previously referred to as "object management" will now be called "object access". This facility provides a general model for such functions as periodic query, saving of result sets, and off-line printing. These are functions that real-world database search systems offer, which would be developed in an ad hoc manner by all the vendors if there were no standard way provided by Z39.50. The current proposal includes a matrix of objects and operations. There will be a separate PDU for each operation, a core set of objects that will go in the standard, and a mechanism for registering additional object types. Certain objects permit certain operations, as shown in Table 1 of the doc. Discussion: There was much discussion about which objects and operations should be included in this facility (especially for V3). It was suggested that a messaging service is perhaps too specific, and that we postpone messaging for now. Defer the Permit, Lock/Unlock functions for now. Concern expressed over the "destablilizing effect" on the standard, especially where the proposal overlaps with existing or proposed functionality. Delete PDU overlaps with current Delete Result Set PDU for transient info. There is a separate RLG proposal for the SORT function. Issue: Should a 'transient result set' be considered an object and allowed to be manipulated with these facilities? No:It will de-stabilize the standard. Yes: It is a logical extension of the object paradigm. No: But the existing standard is not an object paradigm; the Object-Access facility is an additional service. It should not force re-thinking of the existing implementation. Perhaps it would be better to think of Search as an operation that Creates a transient result set. It may be a useful thing to provide a new operation to stage a persistent result set into a transient result set and vice-versa. (Impose a fire wall between persistent and transient objects). Need to define whether or not Transient Result sets allow the same operations as persistent result sets. Ray requested specific semantics for each cell in the object/operation matrix. The following approach was suggested for furthering the proposal. First, define the service, then the protocol. Need a clear definition of the application model. Other suggestions: The doc should have a section prepended that gives a list of short problems that this facility addresses. Make each column of table 1 a separate PDU. Or (alternatively) define 1 PDU for each logical group of operations. Rename "Save Result Set" to be "Create Persistent Result Set". Put one bit into the INIT PDU to say if Persistent Objects are supported to provide a single point at which all these operations are disabled so that simple implementations won't have to support individual refusal of all the associated PDUs. Also suggestion for 1 bit in INIT for each separate service. Tentatively, (at the end of this day) the operations agreed to be included in V3 were: create/replace, list-instances-of, delete, export, retrieve, activate/deactivate/test, status. For delete, the current delete facility will be enhanced. The core objects are: transient result set, persistent result set, query, and periodic query. For after V3: Permit, Lock/Unlock. The maintenance agency will add a node in the oid tree for object type. Temporarily, the value 1009 may be used. < Discussion adjourned until next day, June 2 > 11. IR-Object-Access-Facility (Continued) ممممممممممممممممممممممممم Discussion: Export profile added to object list. Debated various models of the Object-Access facility. There are several conflicting ways of viewing the facility. Taken too far, it can de-stabilize the standard. There are fundamental issues of scope of protocol, and the scope of the functionality of this facility that need to be sorted out. Resolution: A sub-group will try to hash out some of the issues at lunch and, if necessary, at dinner. The goal will be to get enough closure at this meeting so a minimum set of required functions can be built by those vendors needing them, without having those implementations disrupt the standard. Peter, Ralph, Denis, Les will come up with definitions of the basic PDUs. Use Init bits to negotiate each of the service PDU's; at least during the development process. Avoid overloading existing operations. Enhance existing Delete PDU. Perhaps avoid use of the "Object" term, to prevent confusion. The maintenance agency will add a node in the oid tree for object type. Temporarily, the value 1009 may be used. Peter will come up with prose for the next meeting for submission for the Version 3 doc. 12. Info-1 deferred until later in the agenda. 13. Sort (Stovel) مممم The RLG proposal for Sort (ZIG92-033) was discussed. Discussion: What sort information does the client need to pass to the server? How is the information sent? A richer set of Sort relations was suggested, including lexical and numeric. A sort should allow lots of flexibility in sorting criteria, including relevance ranking information. Record elements and Search elements of a database are generally not the same (except for info-1). Which should be able to be sorted? What should "the thing you sort on" be called? Field? Atribute? Element? Use "Use Attributes" as the thing you sort on, and add a bit to delineate if the Use Attribute was a sortable, and/or a searchable one. Should sorting create a new result set, or re-order the existing result set? Q: Is a sortable result set usable in a query? Q: Is it a different result set? A: yes. The standard says a result set is ordered. But chances are you get the same answer to subsequent queries on subsequently sorted result sets. Should Sort be in a separate service (new PDU)? Should Sort be included in a search request? Should Sort be included in a present request? Without having a sort PDU, if you want to sort an existing result set, submit a search on the result set, with dataset name as UNIVERSAL, and Query is a single operand of old result set name. If sort is not supported within a search, then you report a search attribute problem. It was suggested that Sort allow more than one result set to be specified as input to the sort. Agreements reached: the origin should be able to specify and name an output result set resuting from the sort; the capability to turn sorting on and off (as a mode) is not needed; the search request should have an optional sort parameter so the target can be advised in advance how the origin wants the result set ordered; however, there need not be such a parameter on the present request, instead, a separate sort request (PDU) can be issued. Explain would be used to discover the elements amenable to sorting. A sorted result set will be usable in a query. There was consensus that one should not have to go to the additional trouble of creating a persistent result set before allowing a sort. The Sort service may be negotiable using a bit in the Init. Resolution: Lennie will update the proposal based on these and other comments, and post the changes. Ray will write up a position on whether the Sort service may be negotiable using a bit in the Init. . 19. Compiler-friendly ASN.1 coding guidelines (Kunze) ممممممممممممممممممممممممممممممممممممممممم John Kunze distributed and discussed proposed ASN.1 guidelines for the preparation of future ASN.1 modules for Z39.50 (ZIG92-039). Discussion: Applies to both users of ASN.1 compilers as well as hand coders. These issues may not be important to first implementations, but grow in importance as you write subsequent versions and maintain the code over time. Everyone should read the doc, and suggest changes. John hopes that at the next ZIG this doc can be adopted as something formal. Area 1 and 2 changes are cosmetic changes which don't affect the substance of the standard. Ray Dennenberg considers constraining CHOICE to be too drastic. The goal of the document is not to impose a universal specification, but to try and minimize the number of local changes required to get the standard ASN.1 to compile. Resolution: The proposal to name each instance of a type was accepted. The suggestions to not use CHOICE or SEQUENCE except after "::=", to avoid hyphens in values and types, and to use short identifier lengths were rejected. There was no apparent consensus on the proposal to minimize primitive types referenced. The proposal to reflect sequence order was not understood. There had been a separate but related proposal (from Simon Spero) to move context specific tags to the sequences or choices where they are referenced, rather than defining them globally. Duplicating the tag definition in the multiple PDUs improves readiblity for hand coders. Also, as an "addendum" to the Kunze proposal, some specific cosmetic changes were proposed for the RPN query. Both of these proposals were accepted and will go into version 3. It was agreed that two official versions of the ASN.1 will be maintained and kept synchronized by the maintenance agency. The first, "standard" version, will emphasize human readability, the second, "implementor" version, will emphasize compilability. The two versions will be absolutely bit-compatible in terms of BER output. 14. Resource Control and Cost Limits (Denenberg) مممممممممممممممممممممممممممممممم Discussion: The Resource control proposal is gaining acceptance among TC46 members. Some people expressed reservations about the lack of a cost limit feature. Cliff and Mark recollect that some people opposed the Resource Control proposal UNTIL cost limits were added to the proposal. It could be done by setting a flag in Init to return a Resource Control when a particular limit is reached. But this won't work for Concurrent Operations, unless the flag is meant to pertain to any operation, rather than the association as a whole. Fulfilling every possible requirement is a quagmire. Perhaps we should find some simple feature that gets some basic features. Two interesting cases: (1) Hitting a value of a pre-paid amount cumulatively across several operations. (2) Stop an operation when it hits a certain expenditure. Negotiations: Searches where the target doesn't think it can't abide by the cost limit could return a diagnostic. It is expected that Cost limits are an inevitable requirement at some point. Definition of meeting/exceeding limit: Good faith attempt by target to do the right thing. It is outside the standard to specify what happens when the resource is exceeded. An option is to offer the results contingent on paying the exceeded value. 5 Proposals: (1) Put cost limit per PDU; (2) Modify Resource Report Request; (3) Put something in init; (4) Have target notify user immediately if operation is costly; (5) Express it through the object management facility as a user option, another type of persistent object. Resolution: Put a parameter in Init or in the Resource Control request to set cost limits. It essentially says to return a resource control report if any particular operation in an association will hit a particular "limit". In the event that the target realizes that it will exceed the proposed limit it will notify and not perform the operation. If origin specifies a limit, the target can reply that limits either are or are not supported. If resource control supported, a resource control message is sent to describe the limit being approached/exceed. If resource control is not supported, the target will terminate the operation if the limit is reached. Ray will outline the various approaches discussed at the next TC46 meeting. If SR doesn't like this method, we'll get clarification and try again. 16. Access to generic databases (Kunze) ممممممممممممممممممممممممممم This discussion was based on one of John Kunze's Info-1 documents (ZIG92-035). John is looking for feedback. Discussion: ISO has a generic date format, which should be used. Term name ObjectID is problematic. Add time to the record update date. If you use pure dynamic tags, it's unlikely that the client with have a deep understanding of what the data is/means. The generic tags are an attempt to enumerate some of the generically useful tags so you don't use dynamic tags all the time. Generic tags correspond to info-1 Use attributes. It was requested that Info-1 tags be expanded from 16 bits to 32 bits. It is possible to use the bib-1 attribute set for searching, and info-1 for delivering answer information. Definitions: Concern was expressed about use of the term "Field". We need to define terms carefully, and use them consistently throughout the standard, and its various services. Field might be an element or an element fragment. But the term Element, on closer inspection is not as well defined as we thought. Suggestion to define Element as the minimal addressible semantic data component of the protocol. It depends on who you are, what you can see, and what you know. An Element Set Name identifies a procedure which a target system executes to determine the composition of the record to be transferred. That algorithm may follow a static list but need not be. Part 4 (final segment) of minutes June 3 15. Fragmentation of data fields (Kunze) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This discussion was based on John Kunze's "Fragmentation of Information in Z39.50" document (ZIG92-034). The issue is referred to as fragmentation (or segmentation - there was disagreement on which term is appropriate). There appears to be a critical need for a target to return multiple PDUs in response to a single present request. One reason is that with high-speed networks, if the size of a single message is limited and if a request must precede each response message, response time will be drastically affected. This means that response messages must be segmented. Three cases are considered: (1) segmentation at record boundaries, (2) segmentation of a record, and (3) segmentation of a field or element. Segmentation at record boundaries can be accomplished by including a "more" bit in the Present response, and returning to the same state. The present request would include a "multiple present response ok" flag. Segmentation of database records can be accomplished by adding a third "record type"; i.e. currently 1 = Database record and 2 = diagnostic record. The proposed solution is to use 3 for "database record segment" (could use 3 for "partial record, not last segment" and 4 for "partial record, last segment"). Diagnostic records would not be segmented. The solution for case 3 (segmentation of an element) was not as clear. Record set Fragmentation: We now have a syntax for selecting elements out of a record. It would be legal in the protocol, but a mistake to chop out an element, and not send it if the resulting record would be too big to fit in a single PDU. Some see a need for target initiated fragmentation for large record sets where what you will get back is multiple ADPUs. That a record cannot span more than one PDU in Present is coming to be viewed as serious, but easily remedied defect in the protocol. You need an indicator in present asking if it's okay to fragment and a bit in the PDU that says "there is more data coming". How do we decide when to segment, and when we just don't want an ADPU that's very big? Element Fragmentation: Target or origin initiated. Do we need some server-driven method of fragmenting? Since there is a requirement for a syntactically correct record, a problem arises: The client would be getting records with arbitrarily complex transfer syntaxes that would have to be recognized as fragments, analyzed and re-assembled into larger records. It would be simple to define a new record transfer syntax, and encapsulate fragments in it. Call it an octet string. Then the string may contain a piece of a larger ASN.1 structure. This is re-assembled when all the fragments have been transmitted. This method accomodates both large incrementally processable PDUs and large PDUs that must be handled as a unit. Resolution: Ray and Clifford will work out the details, and Ray Denenberg will draft cases 1 and 2 for version 3. John is going to work up a new doc on case 3 (fragmentation) with help from Ralph and Clifford. Day 3: June 3, 1992 17. Variant records (e.g., document types) (Kunze) ~~~~~~~~~~~~~~~ This discussion was based on John Kunze's " Variant and Document Retrieval" document (ZIG92-036). John requested comment on this. The point is to allow the client to browse variants of documents, with more granularity than currently provided by specifying the record syntax. Locally registered object ids would allow retrieval of specific variants of individual elements within a record. This information would be carried in the element set name field of a Present Request. It was also noted that it is not yet possible to specify multiple preferred record syntaxes in the same Present (proposed for V3). 26. Multiple preferred record syntax (Waldstein) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This was a proposal by Bob Waldstein to be able to specify multiple preferred record syntaxes in the same Present. See the V3 features document (ZIG-92-026) section 18. Bob wants to add a third option: A sequence of abstract syntax names with no database specified. Furthermore, would like the precedence of the syntaxes to be significant (ordered sequence). 21. Version 2 status report and discussion of changes (Denenberg) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~ Two negative votes resolved. One late negative vote resolved. One Yes vote with comments received. The comments seem to be a wish list which seem like Version 3 suggestions. Editing changes are underway to address the comments. Changes: Proximity, Access Control (from Octet String to External), and Resource Control (externalize). ALthough there won't be a review possible for these, they'll be made because they are technically important, and they won't negatively impact existing implementations. Issue: Was there a conscious decision to drop alphabetic currency codes? Ray requested a letter from the ZIG verifying that this change is valid, there is compelling technical reason, and that we want the changes to go into V2. One of the late version 2 changes proposed is to make the security report parameters of the Access Control request and response External. However, until there is at least one report format registered, no one would be able to use Access Control. Therefore, the change will be to make the parameters a choice between (the current) OctetString and External. The value 8 under the Z39.50 OID tree is designated for security report formats. The final V2 text will go to NISO for publication ASAP (1 month minimum). It was noted that the publishing step takes too long. Final text will be available by the next meeting. Pat Harris at NISO can provide copies of the official version of the standard upon request. It was noted that it would be nice to put the V2 standard online. ASN.1 will be available electronically. Mark offered to convert Ray's WordPerfect version of the ASN.1 to ASCII and Postscript versions. Jim and Cliff will continue to push for electronic versions of the NISO standards. 22. Version 3 feature description (V3D3) -- MA-021 (Denenberg) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This discussion was based on Ray Denenberg's "Z39.50 V3 Feature Description (Third Draft)" (ZIG92-026), and changes below refer to that document. This represents the most current thinking on V3, but is subject to change. Changes discussed: Convert features number 2 and 3 and replace them with the "Persistent Information Service". Number of result sets (feature 4) got lots of discussion. Needs to support indeterminate number of result sets kept. Issue of impact on WAIS and stateless servers. Peter will state his requirements on result set numbering. The parameter Number-of-result-sets will be changed to a Boolean flag: "Named-result-sets-supported". It is felt that negotiation of the actual number of result to be used by an origin or supported by a target is not meaningful. It is more likely that the aggregate storage used by all of the result sets would be limited, rather than the number of result sets. In the case where the actual number is limited by a target, it is usually a static number, which could be determined by Explain. Ray will write up a proposal on this. Is suspend/resume in version 3? No. It seems to be an SR issue, and people here at the ZIG are not expressing the requirement. It would help if we could put it aside. Is concurrent operation in V3? It can be added back. Agreed to incorporate Terry's new proposal into V3. Lennie wants Sort to go into version 3. It's as far along as many other things going into V3. AttributesPlusTerm: The V3D3 feature to include an AttributeSetId with each operand in a type-1 query includes a proposal to make the "Term" optional in a Type-1 query. The group rejected this proposal. In the current standard a query operand is an attributeList/Term combination. The essential V3D3 proposal is to optionally append an Attribute set id to each attribute list. Thus an operand would be an attributeSetId/AttributeList/Term combination. However, the requirement is to have multiple AttributeLists, from different attribute sets, with a given Term. Thus the agreed form for AttributesPlusTerm is: AttributesPlusTerm::= CHOICE{ v2 [102] IMPLICIT SEQUENCE{ AttributeList, Term}, v3 [xxx] IMPLICIT SEQUENCE{ attributeList [1] SEQUENCE { [1] AttributeSetId OPTIONAL, [2] AttributeList}, term [2] Term OPTIONAL} Clifford wants the "Information extension in search response" moved from V4 to V3. It will be added to the survey. Clifford will produce a doc that can be ZIG'ed that will codify what he sent in email describing it. Side issue: We keep revisiting issues after we've forgotton some of the fine points of the rationale for the various issues. Can we improve this situation? Changes to minutes? Special Minutes taker unaffiliated with the discussion? An issues document? It would be good if there were a statement of consensus or closure for each adjenda item. Alas, most of the time we just don't come to closure. Having an "issue champion" helps and frequently solves the problem. Historical rationale should be maintained in the various papers. 7. EXPLAIN ~~~~~~~ Joe Zeeman wrote up the ASN.1 for Explain, distributed at TC46, and asked for comments. It was agreed Cliff would take Explain over again, and write up appropriate prose. Discussion at this meeting impacts the current Explain spec. Explain is not yet stable, but several need to start implementing it. It would be useful to have a couple of implementors (like FCLA and AT&T) implement Explain, and find out what's missing. Cliff will revise Explain by the next meeting. 4. Z39.50 Implementors Group Profile -- MA-026 (Denenberg) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The document "Z39.50 Implementors Group Profile" will be designated MA-026. It is yet to be created, but the reference will appear in GOSIP, version 3. It will be based on the current ZIG PRL. ZIG members are requested to fill out the PRL, with values reflecting their implementation, and it is hoped that a consensus profile can be developed. There is interest in having the PRL online so that members can fill it out electronically. Hinnebusch volunteered to convert the document, which is now in the form of WordPerfect tables. N. RFC 1006 ~~~~~~~~ Denis Lynch suggested ZIG consider the value of running Z39.50 over TCP/IP using RFC 1006. This is the technique used by ISODE to allow OSI applications to run over TCP/IP. It involves encapsulating TP0 over TCP. The value of this approach is that it moves closer to interoperability with OSI systems, and leverages the session/presentation features, so that they don't have to be reinvented in the application layer. ZIT has decided not to use this approach, at least in the short term. But Denis suggested that this approach might be worth doing in the long term. The ZIT view is that simplifying away the OSI stuff helped a great deal in getting implementations going initially. Cost of features such as Suspend/Resume, Recovery or transfer syntax negotiation is about the same to do in OSI kernel as it would be to do it with a unique implementation. Is the cost of an OSI kernel prohibitive? We would like to see what the implementation of the various features using OSI layers would look like. Denis will continue to look at this. Future Meetings ~~~~~~~~~~~~~~~ September 23-25 at RLG, Mountain View CA December 9-11 at FCLA, Gainsville FL April 1993 in Washington D.C.