Z39.50 IMPLEMENTERS GROUP 7th meeting held in The Beatles Conference Room at Apple Computer, Cupertino, California December 9 - 11, 1991 Attended by: Ralph Sprague Apple Computer r.sprague@apple.com Kevin Tiene Apple Computer tiene@apple.com Janet Vratny-Watts Apple Computer watts@apple.com Steve Wolfe Apple Computer wolfe@apple.com Kazu Yanagihara Apple Computer kazu@apple.com Les Wibberley Chemical Abstracts Svc. lhw25@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 Stu Soffer Data Research stu@dranet.dra.com David Loy Dialog Denis Lynch ESL Inc. dml@esl.com Mark Hinnebusch FCLA fclmth@nervm.nerdc.ufl.edu Terry Sullivan FCLA fcltps@nervm Ray Denenberg Library of Congress bb.ray@rlg.stanford.edu Larry Dixson Library of Congress ldixson@ldix.loc.gov Peter Ryall MDC peterr@meadata.com Tom Owens MIT owens@athena.mit.edu Sara Randall NOTIS Systems Inc. randall@nuacc Ralph LeVan OCLC rrl@rsch.oclc.org Mitra Pandora Systems mitra@pandora.sf.ca.us Lew Jenkins Premenos lew@enlil.premenos.sf.ca.us Manny Pasetes Premenos ekp@enlil.premenos.sf.ca.us Jui-wen Chang RLG br.jxc@rlg.stanford.edu Rich Fuchs RLG br.rbf@rlg.stanford.edu Lennie Stovel RLG bl.mds@rlg.stanford.edu Peter Tam RLG br.pct@rlg.stanford.edu Belinda Reed Software Kinetics bjreed@crc.sofkin.ca Joe Zeeman Software Kinetics zeeman@crc.sofkin.ca Rich Levitt Stanford University rlevitt@forsythe.stanford.edu Bo Parker Stanford University ga.spb@stanford Andy Bensky Sun andyb@sun.com Brewster Kahle Thinking Machines brewster@think.com Harry Morris Thinking Machines morris@think.com Margaret Baker UC Berkeley margaret@garnet.berkeley.edu John Kunze UC Berkeley jak@violet.berkeley.edu Cecilia M. Preston UC Berkeley cpraeston@info.berkeley.edu Cliff Lynch UC DLA calur@uccmvsa.ucop.edu Michael Thwaites UC DLA mjtol@uccmvsa.bitnet Margery Tibbetts UC DLA mztuc@uccvmsa.bitnet Mark Needleman UC DLA mhn@stubbs.ucop.edu The group discussed the agenda items in the following order, which is maintained in the notes: 1. Introductions and status reports 2. NLC SR/Z39.50 Kernel 3. Ballot version of Z39.50 version 2 4. Version 3 of Z39.50 6. Proposed enhancements 6.1. Document identifiers 7. Range support 9. Set manipulation/management 10. List result sets 11. Regular expressions 5. Version 3 - details 5.1. Close, suspend, resume dialog 5.2. Periodic query 5.3. Save result set 5.4. Browse 5.5. Explain 8. Searching result sets 5.6. ASN.1 redirection 5.5.1. Dynamic attribute set and generic record syntax 12.2. Encoding rules for terms 5.5.2. Preview of record by present 12.1. Element set name for record fragments 13.5. Multiple present response PDUs 15. Private query types 14. "Any" and "default" user attributes 11. Regular expressions (continued) 18.1. Security 20. ASIS report 17. Common APIs 16. TCP/IP 21. New attribute sets 18. Next meeting time/place 1. INTRODUCTIONS AND STATUS REPORTS FCLA: Protocol manager code is in place. Expect to be operational by June 1992. Are using both OSI and TCP. UC DLA: Has an operational server and client on IBM 3090, talking both to Penn State and themselves over TCP. Available for testing. The software is not robust enough yet to put up for public use but that is a goal. DLA's code for BER encoding and decoding is available. UC Berkeley: Server ID and client are talking to DLA and Penn State, not talking well to themselves. Dialog: Observing. Premenos: Premenos is an Electronic Data Interchange (EDI) software provider, in the ISO world to date. They are developing the capability to use the Internet. Dartmouth: Dartmouth's campus-wide information system is in place; undergraduates get a copy of the interface software. Eric Bivona has made a proof-of-concept version of a protocol gateway between the CWIS and WAIS. Next he will do a gateway to Z39.50 version 2. Columbia Law School: Has been working with Thinking Machines/WAIS. NOTIS: Is beta-testing Paclink, a NOTIS-to-NOTIS interface. They are working on full Z39.50 support with BER encoding. Apple: Observing. Stanford University: Getting started. Data Research: Seeing if their Z39.50 implementation is compatible with UC DLA's; expect to be able to connect with DLA within a few weeks. Library of Congress: Working with IBM in Italy to make IBM's OSI product useful. Support for recursion has been added to the ASN.1 compiler. LC has 6 test queries with 4 operands and 3 operators working. IBM corrected a problem with EXTERNAL types; a problem with length remains. Mead: Implementation phase is starting; connections are possible in February or March. OCLC: The full text workstation using Z39.50-1988 is in Quality Assurance. Starting on version 2 over TCP. Chemical Abstracts Service: Following progress. RLG: Protocol machine and search engine are working; BER encoding and decoding and a TCP/IP interface are coming along. Have looked at IBM's OSI product for the PS/2. MIT: Are considering joint development with DEC using Carnegie-Mellon software. Thinking Machines: Second generation products are nearly done; still based on version 1. Sun: Z39.50 implementation is based on Sun's RPC method for TCP/IP. [The Sun implementation was demonstrated and discussed at Sun the previous day.] CNI Testbed: Clifford Lynch announced the formation, under the sponsorship of the Coalition for Network Information (CNI), of an interoperability testing group, whose goals are to get demonstrations up quickly and to make interoperability visible. The group has six or seven charter members and is looking for others who have a short time frame and an interest in TCP/IP, including institutions who have not necessarily been represented at ZIG meetings. The first meeting will be held in January. A demonstration is planned for the Net 92 meeting in March. WAIS: Brewster Kahle mentioned the various platforms for which WAIS clients have been developed, and said that there are 115 registered WAIS servers plus other private servers in seven countries. It is possible that the University of North Carolina will take on the role of coordinating WAIS use and development. 2. NLC SR/Z39.50 KERNEL Joe Zeeman distributed a description of the National Library of Canada's SR Kernel Project (ZIG 91-39). NLC wants to encourage use of SR (ISO 10162 and 10163) by making a platform-independent implementation freely available. Before proceeding, NLC needs expressions of interest from implementers who would use the kernel as a basis for development. The kernel will contain a protocol engine and a sample client that will run on several platforms, possibly using ISODE. There might also be a sample target application using SQL. Two documents describe the work to date: "Software Requirements Specification for the Search and Retrieve Kernel" and "Interface Requirements Specification for the Search and Retrieve Kernel". Comments on these documents can be given to Joe Zeeman. 3. BALLOT VERSION OF Z39.50 VERSION 2 Ray Denenberg referred to the ballot version of Z39.50 version 2 (ZIG 91-41), which NISO had mailed to ZIG members. He pointed out that it includes definitions for resource control and for a proximity query. Comments from people who are not NISO voting members will be considered though they are not given the same priority as comments from NISO members. Compliments are due to Larry Dixson for providing the accompanying document on the bib-1 attribute set (ZIG 91-42), which will help NISO readers who have not followed the standard closely. Highlights of the changes since the last version: Page 1, last paragraph of section 2: "For the purpose of retrieving records" was added to the description of the structure of a result set. Page 2: definitions for Conditionally Confirmed Service, Confirmed Service and Non-confirmed Service were added to support the modeling of the Resource Control Facility. These definitions do not appear in ISO TR 8509. Pages 3, 11-13 and 21-22: The Accounting/Resource Control Facility is now described in terms of three services, Resource control (conditionally confirmed), Trigger resource control (non-confirmed), and Resource report (confirmed). Page 4: The Options have been expanded to account for the new services. Pages 6 and 18 and Appendix G: Proximity query has been added. Appendix G includes a note about the use of the proximity operator when one or both operands is a set. Page 22: Currency code information provided by Joe Zeeman has been added to the Estimate. Pages 23 and 24, section 4.2.2: New notes (1) and (2) describe the primitives used in the protocol model for the new services. Pages 25-28: The state tables incorporate the new services. The state "ignore" has been added to indicate that this state is not a protocol error. Page 34: New Conditions and Meanings have been added to the diagnostic set bib-1. In some cases the Addinfo column gives an indication of what additional information might be provided in the diagnostic record. Page 35: Units have been added to some of the resource reports. Joe Zeeman asked about the situation of having two object identifiers, one in the ISO member-body US tree and one in the ISO standard tree, for identical record syntaxes. Ray felt adding a note to this effect is warranted. 4. VERSION 3 OF Z39.50 Ray Denenberg distributed "Z39.50 Version 3: Feature Description" (ZIG 91-40). It describes 7 features proposed for the next version of Z39.50 that had been discussed in varying detail by the ZIG: 1. Close, Suspend, and Resume Dialog 2. Periodic Query Facility 3. Save-result-set Service 4. Browse 5. Explain 6. Searching a Result-set 7. ASN.1 Indirection Close, Suspend and Resume Dialog Closing a dialog means to finish the session but keep the association open for another session. Suspending a dialog means to stop it with the intention of resuming it later in a different association. Closing and suspending require making a distinction between a dialog and an association, by means of an additional parameter, Dialogue-id, in the Init request. This might also require more latitude in ignoring parameters in the Init, in order to maintain upward compatibility. Under the rules for extensibility, a bit could be added to the Init Options to indicate that a Dialogue-id is being used and hence multiple dialogs on a connection are possible. Les Wibberley described a use for this facility in which a search service is receiving searches from other search services that are mediating for clients. In this picture the application is multiplexing searches and would need to manage multiple dialogs on the same association, with separate state tables for each dialog. With an OSI stack, the multiplexing would be handled by the session layer, not the application layer. In connection with this discussion, Denenberg commented that OSI support is still being assumed in version 2 of Z39.50. If NISO members want to change this, they should make this comment in their ballots. [The group discussed each of these features the next day. -Ed.] 6. PROPOSED ENHANCEMENTS Ray Denenberg distributed a list of 25 proposed enhancements to Z39.50 (ZIG 91-43). The group discussed the status of the items on the list, indicating which should be deleted or combined, which should be moved to version 3 if at all possible, and which were a matter of registration not standardization. New items and new editors for some existing items were added. Denenberg also distributed a list of the Maintenance Agency's 13 documents (ZIG 91-44). 6.1. DOCUMENT IDENTIFIERS Brewster Kahle distributed the September 1991 version of his paper "Document Identifiers or International Standard Book Numbers for the Electronic Age" (ZIG 91-46). A document identifier is a description of a document that actually lives on a different server from the one where the search is being carried out. The identifier is returned with a headline for the document in a Present Response, and it can be used in a subsequent Search Request. It identifies both the original document and an "address" for the distributor of the document. It also contains information on restrictions on distribution such as copyright. The name of the document is authenticated by a naming authority that is responsible for uniqueness. Presumably the naming authorities need to be authorized. Other pieces of information and clearer syntax need to be added. Further discussion of the doc-id will take place on the wais-talk list. 7. RANGE SUPPORT Michael Thwaites distributed "Proposal for explicit range support" (ZIG 91-47), a paper that suggests adding an explicit option, AttributesPlusRangeTerm, in the Operand in the RPNStructure. The goal is to avoid repeating the attributes for the terms at each end of the range. It would be up to the target to determine the meaning of "greater" and "lesser" for the specific attribute. There was a discussion of the differences between ranges and truncation (not clearly distinguished) and between ranges and regular expressions, which have pattern matching as their goal. During discussion of this topic the next day, concern was expressed about controlling the bounds of the range. Joe Zeeman suggested added another operator for "between". Michael will write up a description of this alternative and give it to Ray Denenberg. 9. SET MANIPULATION/MANAGEMENT 10. LIST RESULT SETS Peter Ryall noted that a general result set management facility might include saving, sorting, filtering, listing, duplicate detection, and relevancy ranking. Sorting result sets is one of the proposed enhancements discussed earlier as needing a general solution. Filtering the result set refers to making parts of the result set accessible, by specific criteria or by marking records in the set; a subsequent operation could be done on the marked records. Listing result sets is a way of asking what result sets the client can access; it might require a registration mechanism whereby the target gives an ID to the origin, and it might give access to the client's result sets to other origins. Duplicate detection eliminates duplicates across multiple databases used in a single search, or across result sets; it is a variation of sorting. Clifford Lynch pointed out that editing or marking result sets can be done by additional searches. Once the capability to save result sets exists, many options for access open up; how far should the protocol go? Ray Denenberg noted that some access restrictions are described under concurrency control in the save-result-set service in the version 3 features document. Brewster Kahle said that both the client and the server need to do result set management; the question is what belongs in the protocol? Lynch felt that only simple, common actions, especially those appropriate to non-persistent results as well as saved result sets, belong in the protocol. Sorting and listing seem appropriate but perhaps some of the access capabilities are too vendor-specific. The standard uses pointers to records as its model for a result set, not images of database records or searches to be reexecuted. If a saved result set is to be stored as a file of records, then file attributes can be used to control access, and FTAM or NFS or other file manipulation protocols can be used instead of Z39.50. 11. REGULAR EXPRESSIONS John Kunze distributed "Meeting Topics Submitted to the Z39.50 Implementors' Group" (ZIG 91-45; the topics had previously been distributed on the Z3950IW LISTSERV as separate postings). The first part of this document, "Final(?) Proposed Regular Expression Support for Type-1 Queries", includes definitions of two syntaxes, GLOB and REGEXP, which would become structure attributes. The paper describes how current diagnostics could be used to describe error conditions in the use of regular expressions. There was discussion about the lack of external descriptions of these syntaxes, about the possibility of ambiguities, and about the use of characters in the term that are also characters with meaning in one of the regular expression syntaxes, requiring the use of an escape character. It was felt that some implementations might not be able to support all of the masking provided by GLOB; a diagnostic could be used when an unsupported character was encountered. (See Wednesday's notes for further discussion.) 5. VERSION 3 - DETAILS 5.1. CLOSE, SUSPEND, RESUME DIALOG Referring to the description of Suspend-dialogue and the Termination Facility in the version 3 features document (ZIG 91-40), Peter Ryall asked if a suspended dialog couldn't be resumed later in the same association, making the Release following the Suspend-dialogue optional. Ray Denenberg agreed that sounded reasonable. A need for Abort-dialogue was identified as well, for example, if the Target needs to end a dialog that has been inactive for some time. A need for a Dialogue-id in each PDU was identified, for sites that want to multiplex dialogs. Use of the Dialogue-id could be negotiated in the Init. The Termination Facility described in ZIG 91-40 is an additional facility for Z39.50, which will no longer just map to ACSE. The procedures that apply if Session negotiated release is available are optional. A separate state table is needed for the association and for the dialog, plus a state table that accounts for Session negotiated release, which does not require an IR-release. There was discussion of the relation between Suspend-operation suspend-1 and Resume-time. For some applications, there should be an elapsed time prior to resuming, rather than a date and time after which to resume. Also, if the target can resume the dialog, does this mean that the target is to initiate the later association? With a periodic search service, the target would want to notify the client that new results are available. Both sides would have to be able to begin at the state where the previous dialog was suspended. In addition, there needs to be a Suspend-status for a target that cannot support this kind of call-back. Denis Lynch pointed out some of the problems with target-initiated resumption: the presentation context has to be reestablished; dialogue-ids have to be unique; the target has to retain a lot of information about suspended dialogs; the resume might come from a different client but should still be accepted. Others asked whether the protocol should support resuming after loss of a network connection, without a Suspend request. There was a general discussion of security and authentication with a resumed dialog. Clifford Lynch made the following suggestions: When the client resumes the dialog, use the authentication facility in the Init Request, or require a password on the resume. Or, an authentication parameter in the Resume-dialogue could be used by either the client or the target who is calling back. He felt that people will reject an association by the target, then place their own calls to resume the connection; then the target-initiated resumption becomes a notification. The target could offer to hang up after the notification by means of a bit in the Resume-dialogue service. John Kunze agreed that though this suggestion is awkward, the idea of notification seems important. Peter Ryall suggested allowing targets to resume dialogs only if a client-initiated association exists. Other objections were voiced; discussion was to resume following the discussion of periodic searching. 5.2. PERIODIC QUERY This is the second item in the version 3 features paper, ZIG 91-40, where the Periodic Query facility is described as consisting of three services: Define-Query-profile, Start-periodic-query, and Stop-periodic-query. It was noted that returning the results and notifying the client of results could be outside the protocol, though the capability to request an alert or to specify a delivery method is included. The Define-Query-profile includes a capability to execute the search immediately if desired; there was some discussion whether this should be possible, and whether a query in a Search-Request could refer to a defined query. This might lead to difficulties with the parameters such as database name that are stored with the query, however. Other variations were suggested. It was pointed out that a query management facility would also be needed, for example, to list or delete stored queries. Also needed are rules for what to do if a stored query is not present when it came time to process it. Since similar facilities are needed for result-set management, perhaps a generalized object management facility with parameters is called for. Other comments were that an Alert and the Results might both be wanted, and that more detail was needed in the Delivery-method. The possible interaction with periodic results was noted but discussion was deferred. The need to override portions of the Query profile (database names, for example) at the time of Starting the periodic query was mentioned; this might imply a new name for the query. Ralph LeVan volunteered to work with Ray Denenberg on writing up object management; others should send their requirements to the list. John Kunze listed some of the basic issues: context saving; activation and deactivation; and rendezvous or call-back versus notification. 5.3. SAVE RESULT SET The third item in the version 3 features paper, ZIG 91-40, describes the Save-result-set Service (persistent result sets). Discussion was deferred until the description of the generalized object management facility is available. 5.4. BROWSE The fourth item in the version 3 features paper, ZIG 91-40, is basically the same proposal as was distributed at the last meeting (ZIG 91-27 and ZIG 91-28, draft addenda to ISO 10162 and 10163). John Kunze's reaction to these papers is included in ZIG 91-45. He observed that the word "browse" means too many things to too many people, and he suggested that the problem that the proposed Browse service is designed to solve would be better solved using existing Search and Present services with a few extensions. The suggestion involves providing names for indexes that can appear as DatabaseNames in a Search Request. The target creates a result set consisting of the entire index, which can be viewed by means of Present Requests. In this model, Browse is viewed as a search without a result set, or with an unlimited result set. Another alternative suggested was to use Search Requests with an indication of whether records were wanted in the set bound parameters, and with the capability for a negative index in Present Requests. Rich Fuchs suggested adding an element to the search to distinguish between searching, browsing an index, and browsing records in access point order; other portions of the Search Request map well to Browse. There was disagreement about whether a separate PDU is needed to do a "traditional browse". Ralph LeVan favored having the client be able to give a starting point and the number of surrounding things. He does not see the need for being able to go on from a given point; rather a new seed term should be provided in each request. In other words, the origin should control the navigation and should in essence re-search each time; other people just wanted to see database records in a browseable order. Various compromises were suggested. Mark Hinnebusch agreed to a separate Browse service if it is renamed ("Term Scan" was proposed) to indicate its function as an index browse; he will proposed a database browse as an extension to Search and Present. The current proposal does not contain continuation (going on from a given point); the ability to browse a result set should be eliminated as well. Other comments were that the Direction parameter is redundant, as it can be inferred from Position-in-response and Number-of-entries; the Use attribute needs to be nameable; additional work is needed on the definition of Entries; a number of postings is needed, and possibly additional information associated with the term; an abstract syntax for Entries that is external to the protocol is needed; a browse on multiple use attributes should be possible; a structure attribute might be needed to distinguish between, for example, title word and title phrase indexes; databases need to be namable, and each term in the response needs to be associated with a database. It was agreed to replace List-id with AttributesPlusTerm, DatabaseNames, and AttributeSetId. Starting-point-in-list is not needed since the term is in AttributesPlusTerm. This provides no way to browse from the "top" of an index, since the "top" might not be obvious. Additional diagnostics are needed, for example, to note why a Browse-status of warning was given, or to indicate that step size is not supported. Other types of "browse" include: 1. Navigation through a database; record scrolling 2. Browsing though the record itself, for example, to get to the part of the record that contains the term used in retrieval; requires solving segmentation problems 3. Navigation through a thesaurus 4. Hierarchical node browse 5. Hyperlink browse 6. Browsing result sets; result set sampling 7. Browsing a list of persistent objects 5.5. EXPLAIN The section on Explain in the version 3 features paper (ZIG 91-40) was based on a document by Clifford Lynch. Clifford will post an update of his previous document, which will include ASN.1 definitions, an attribute set and a record syntax using ASN.1-structured records. It is based on the concept that Explain is a searchable database with lots of data elements. He will also send it to Ray Denenberg for inclusion in version 3, although it is external to the actual protocol. It was clarified that Help is something that is provided by the origin for the user, whereas Explain involves both the client and the server. The client's contextual help might draw on the server's Explain database, as well as on information in the Search and Present Response PDUs. 8. SEARCHING RESULT SETS This is section 6 in the version 3 features paper (ZIG 91-40). No one had any comments on this section. 5.6. ASN.1 REDIRECTION This is section 7 in the version 3 features paper (ZIG 91-40). It tightens the ASN.1 descriptions of RPNQuery and Records to eliminate some indirect definitions, as had been requested at past meetings. 5.5.1. DYNAMIC ATTRIBUTE SET AND GENERIC RECORD SYNTAX The fourth section of John Kunze's paper "Meeting Topics Submitted to the Z39.50 Implementors' Group" (ZIG 91-45) describes an attribute set and record syntax that can be used generically and defined dynamically, so that the same software modules can cope with a variety of databases, for example, library catalogs and phone books. In the "info-1" attribute set, the Use, or Field, attribute is empty initially, and is filled in with values derived from the server's Explain database. The Generic Record Syntax is basically a sequence of Fields. It was agreed that this Attribute Set and the Generic Record Syntax should be registered as a private syntax on the local tree for UC Berkeley, i.e., iso member-body US ANSI-standard-Z39.50 attribute-set (3) local (1000) UC Berkeley (2) info-1 (1) and ... record-syntax (5) local (1000) UC Berkeley (2) generic (1). [The Maintenance Agency should verify this. -Ed.] Element names are positional in the Generic Record Syntax. The actual name of the field is also gotten from an Explain. This does not allow for multiply occurring fields. An alternative was suggested: add a Tag to each Field. John will consider this alternative and other ways to meet this need. 12.2. ENCODING RULES FOR TERMS Lennie Stovel had sent email describing the various standards and other documents to use in encoding query Terms, which are defined as OCTET STRING in Z39.50. Michael Thwaites pointed out that ASCII and ANSEL conflict in the encoding of some characters they have in common, and that some of these characters are used in regular expressions. He also pointed out that a base character set needed to be defined. There needs to be clarification on the use of escape sequences as well. It was also noted that since AddInfo is defined as a Visible String, it can't hold the Term. Ray Denenberg said that AddInfo will be changed to OCTET STRING in version 3. 5.5.2. PREVIEW OF RECORD BY PRESENT 12.1. ELEMENT SET NAME FOR RECORD FRAGMENTS 13.5. MULTIPLE PRESENT RESPONSE PDUS A desired capability is to get a piece of a record in a Present Response in order to preview it before getting the entire record. This is similar to using an element set name meaning "brief", but without the restriction of using a set of elements predefined by the server. The second section of John Kunze's paper "Meeting Topics Submitted to the Z39.50 Implementors' Group" (ZIG 91-45) proposes allowing for two kinds of ElementSetName, a primitive one and a structured one. If an ElementSetName begins with a colon, it is structured; otherwise it is primitive. The structure consists of pairs of keywords and values. Examples of keywords are "start", "end", and "recordformat"; values could be the starting and ending points of a record fragment. This proposal could be adapted to handle the preview function. It could be used with version 2 of the protocol as is, but the requirement needs to be addressed in version 3. Some possible alternatives are to add "start", "end" and unit specifications to the existing PDUs; put the proposed structure in the PDU; make ElementSetName EXTERNAL; make ElementSetName a choice between a simple name, some basic chunking mechanism, and EXTERNAL; allow the target to chunk the record and give the client a "magic cookie" that the client sends back to get more. Denis Lynch pointed out that re questing the best chunk is related to the nature of the data, while dividing a large object up into manageable pieces is best handled by the server. Multiple Present Response PDUs (without intervening Present Requests from the client) are a way to handle the latter though perhaps it can not handle every segmentation problem. 15. PRIVATE QUERY TYPES It was determined that private query types could be handled by using Type 0 with an internal tag that indicates the type. 14. "ANY" AND "DEFAULT" USE ATTRIBUTES Lennie Stovel and Mark Hinnebusch had collaborated on a definition for an "Any" Use attribute and for a description of how to handle the absence of a Use attribute (server's option); this had been sent out in email. The definition of Any implies that Term is any field in the record; the server makes its best effort to look everywhere without guaranteeing it. It was agreed that a number would be assigned to the new Use attribute Any. 11. REGULAR EXPRESSIONS (continued) A question had been asked about POSIX standardization work on regular expressions; John Kunze agreed to check the draft to make sure his proposal matches it. Mark Hinnebusch observed that some implementations will handle some regular expressions but not all; it was agreed that profiling and coverage by Explain will be needed. John will work on additional diagnostics. Lennie Stovel raised the question of distinguishing between title phrase and word indexes; rather than using two Structure attributes to do this, it was decided to move the regular expression attributes to Truncation. 18.1. SECURITY During the course of the meeting, two additional papers were prepared: "Proposal for Specific Security Challenge Types for Access Control," by Andy Bensky and Ed Miller (ZIG 91-48) and "A Proposal for Structured Access Control Information," by Eric Bivona and Michael Thwaites (ZIG 91-49). The two papers agree that the SecurityChallenge and the SecurityChallengeResponse should be defined as EXTERNAL rather than OCTET STRING to enable the possibility of providing some agreed-upon structure for these fields. This is a small change editorially and might be able to be incorporated in version 2. There was a discussion of various forms of security and who is asking for authentication at which point. As it is now, the client cannot ask for identification from the server. It was agreed to add Id-authentication to the InitResponse, but to leave it defined as ANY. 20. ASIS REPORT Clifford Lynch gave a brief report on the session about Z39.50 at the ASIS annual meeting in October. Clifford, John Kunze, Mark Hinnebusch, and Jim Michael had each given presentations, touching issues and implementations. John's presentation on use of Z39.50 in a non-bibliographic environment was especially noted. There was a discussion of how to continue to spread the word about Z39.50, and general agreement that visible interoperability will help. There was also a question about exactly what kind of information is needed; if this were known, it could be provided. 17. COMMON APIS It was agreed that there was a benefit to sharing APIs even if the code itself is not shared, to promote toolkits and use of standards. If Thinking Machines is agreeable, there could be an API subdirectory on the server. Michael Thwaites offered to make available a set of sample BER-encoded APDUs. 16. TCP/IP Clifford Lynch plans to do an RFC for layering Z39.50 on top of TCP/IP based on the approaches discussed in the ZIG. There was a discussion of intermediate networks, composite networks, transport bridges, application bridges, and application gateways. [Clifford explained it all. -Ed.] 21. NEW ATTRIBUTE SETS Les Wibberley said that CAS is working on an attribute set for scientific and technical data. Peter Ryall said he is working on an attribute set for financial data. It was agreed that bib-1 is a core set of attributes, and only additional attributes need to be defined in the new sets. However procedures for inheritance are needed. Tying the database name to the Term instead of to the Query was seen as a possible future need. 18. NEXT MEETING TIME/PLACE Proposed next meetings: March 18 - March 20, 1992, Library of Congress, Washington, DC June 1 - June 3, NOTIS Systems, Inc., Evanston, IL Ray Denenberg requested the group to be prepared to look at the ZIG Profile Requirements List (distributed at the last meeting) at the March meeting. The group expressed its appreciation to Ray Denenberg for his work on version 2 and version 3 and for his participation in the meeting.