MINUTES FOR ZIG 12/9 - 11/92 ATTENDANCE: NAME COMPANY Mark Hinnebush FCLA Mark Needleman UC DLA Cathy Winfrey UTLS Eric Bivona Dartmouth Lee Newman Penn State Ralph LeVan OCLC Sean Donelan DRA Mark Held Carnegie Mellon Cecilia Preston UC DLA Jim Fulton Clearing House For Network Information Kurt Kopp University of Missouri John Kunze UC Berkeley Julie Mills US Government Les Wibberley Chemical Abstracts Denis Lynch ESL Peter Ryall Mead Data Central Sara Randall Notis Ray Denenberg Library of Congress Joe Zeeman Software Kinetics Fay Turner National Library of Canada Lennie Stovel RLG Wayne Davison RLG Brad Mclean Gaylord Info Systems Harold Finkbeiner Stanford Robert Waldstein ATT Michele Dalehite FCLA Gerald Snyder FCLA Terry Sullivan FCLA Deadra Harvey FCLA Nigel Clayton FCLA Lelethe Firth FCLA Gina S. Thorton FCLA Cliff Lynch UC DLA Jim Corey FCLA INTRODUCTIONS: UC DLA, Mark Needleman: Server up 24 hours, client in test mode. UTLS, Cathy Winfrey working very hard on our client more than our server planning on Demo at Mid winter. Dartmouth, Eric Bivona: Has a gateway acting as a client, still experimental. Penn State, Lee Newman Have a server running 24 hrs. client up and running - being tested by libraries staff. OCLC, Ralph LeVan: Setting up link between 88 code and 92 code. Providing access to subsets of their First Search databases. Arrangements can be made for the entire databases. When Z39.50 goes to production, licenses will be for retrieval only, not cataloging. DRA, Sean Donelan: Client is working, but may at times be down may require a call to reinstall. No further work has been done on the server. Carnegie Melon, Mark Held: Project Mercury is currently only access to online library catalogues. Current Work entails: Client upgrade, general maintenance, image browser, text retrieval using Z39.50. Uses NEWTON has a back end. Clearing House for Network Information, Jim Fulton: Funded by NSF, developing Public Domain Server, that will be backwards compatible with WAIS. The code will be based on UC Berkeley's Server. University Of Missouri, Kurt Kopp: Observer. UC Berkeley, John Kunze: No change since last meeting. US Government, Julie Mills: Working on an OS2 Client. Chemical Abstracts, Les Wibberley: Server will perform text and chemical searches. Developing a Scientific and Technical Attribute set. Working with MDL, who are developing the client. Using UC Berkeley's Server for basis, Stanford's Client as basis for Client. Using INFO1 as standard format for chemical structure informational exchange. ESL, Denis Lynch: No progress to report. Mead Data Central, Peter Ryall: Have not provided external interfaces, may have something to show in the next 6 months. NOTIS, Sarah Randall: Has new server using their standard library database. Supports both MARC and Brief record syntaxes. Working on SCAN and EXPLAIN. Library of Congress, Ray Denenberg: Client is fully operational. Software Kinetics, Joe Zeeman: Finish system design for Client, will start prototyping. Server is being developed in Halifax and should be completed by end of the month. Will publish the interfaces in the next few weeks. National Library of Canada, Fay Turner: Coordinating with Software Kinetics. Plan to implement Access and Resource control. Platform is Windows and TCP/IP, May-June time frame for completion. RLG, Lennie Stovel: Has new version of Server. Supports "ANY" or omitted use attributes. Working on Eureka, client on mainframe. Building new indexes for Eureka and will point Server to Eureka. Will also support Scan. Gaylord Information Systems, Brad Mclean: Version 2 production release will be tested soon. Plan to demo at ALA midwinter. Supports type 1 and 100 queries. Stanford, Harold Finkbeiner: Client is in Public Domain and is now available. AT&T, Bob Waldstein: Distributing Client to all platforms supporting sockets. Does EXPLAIN, and supports lots of attributes. Scan may be out of sink. External Server still available. FCLA, Terry Sullivan: Development being done over OSI. Has passed control information to a transaction in the CICS test region and received information from a transaction in the test region. Will connect production system in the test region to OSI/CS using APPC. AGENDA: 1. PROFILES: Introduction: An ISP is a physical document using a formal standard form to establish profiles. An implementors agreement is an informal agreement between separate parties as to what will be supported. This can be seen as a standardize profile versus a conceptual profile. A middle ground is an implementors profile. Currently there are three groups establishing Profiles: NIST OIW: There is a SIG concerned library applications. There was a request that there be a focal point in North America and NIST created the SIG. This group needs participation from the ZIG to be successful. EWOS: European Workshop on Open Systems. Develops EURONORMS. IFOBPS: International Forum on Open bibliographic Systems, has been in existence longest. Discussion: An introduction to profiling was given by the Library of Congress and the National Library of Canada. There was a lot of discussion as to whether the ZIG should be developing a profile. General concerns included the time required for profiling, whether or not the ZIG had enough insight from current implementations for profiling, and if the standard was far enough along to develop a meaningful profile. There was also clear requirements for a profile, which included the documentation of implementors agreements, the need to establish conformance, to develop a guide for new implementations, to be able to provide a concrete document to aid both users and vendors in the development of proposals and specs for new systems, to help in the interaction with SR, and to aid the overall acceptance of the protocol. What does it mean to be conformant to the standard and conformant to a profile, does this guarantee interoperatability? Will a profile state what fields will be used and how they are used? There was also discussion of having a dynamic profile, where only a base set of requirements would be documented and the EXPLAIN database could then be searched to establish the rest of the profile. Questions were raised if this could actually be done. The ultimate goal is interoperatability. Conclusion: As a group, when decisions and agreements are made, then they should be documented, the agreements made by the ZIT will be used for the basis of this document. There needs to be someone to maintain this document, and Ralph LeVan accepted this responsibility. 2. Binary Compatibility with Version 2: This item was dropped from the agenda, since the general consensus was that it would be. A short discussion of Z39.50 and SR pertaining to how to determine which is being used was discussed - this can be determined by the oids and the presentation context being supported. 3. EXPLAIN MAINTENANCE Introduction: There is considerable work being done by implementors on EXPLAIN. There still seems to be areas in this service which are not well defined. Cliff started the development on EXPLAIN, which Joe Zeeman took and developed ASN.1 for, both efforts were consolidated by Ray. Discussion: The discussion focused on the development of a service definition for EXPLAIN and the need for a formal editor. Can the EXPLAIN ASN.1 be replaced with the INFO1 record, is it ready for ASN.1 or does the service need to be refined more? Is INFO1 in a form that is stable enough to with stand international scrutiny? Conclusion: A sub group will be established to develop a service definition, to refine the ASN.1 as needed and to discuss the merits of INFO1. Bob Waldstein volunteered to start the group with help from John Kunze and Ray. A display language will be introduced on the list to be used in EXPLAIN. 4. OSI SKINNY STACK Introduction: An implementation of the upper layers of OSI was developed by Peter Furnace, that uses only a bare set of services. This implementation is conformant to the OSI standard. Discussion: Wayne Davison described the effort in producing the SKINNY STACK and the outcome of the implementation. This OSI stack was implemented in C with a small amount of code. It was fully OSI compatible and successfully demonstrated OSI on top of TCP. The SKINNY STACK provided a means to implement the upper layers of OSI not as separate and distinct modules, but has routines that could be integrated into the application. It demonstrated that the upper layers could be implemented in a fashion that only those services required by the application need to be integrated into the application. Instead of a huge amount of code with bells and whistles that are currently not used, a small amount of code with a well defined API could be used to implement those services of the upper layers that enhance and protect the application. A discussion of how this could apply to Z39.50 then followed. Conclusion: FCLA will proceed to look into the SKINNY STACK to determine the feasibility of it use with Z39.50. Apparently there is a port on TCP for OSI applications. 5. NEW VERSION OF ASN.1 STANDARD Introduction: The new standard for ASN.1 is approaching completion. Several changes to ASN.1 are about to occur. Discussion: Wayne Davison gave a brief over view of the new ASN.1. The type "ANY" has been removed, along with the macro capability of the language. There will be cases where the use of identifiers will now be mandatory. The types for character strings will be changed. The general specification of ASN.1 will be in four parts: 1) Notation, 2) Information object specification, 3) Constraints, and 4) parameterization. Conclusion: None, this was a general introduction to the new ASN.1. 6. LOCAL RECORD SYNTAX REGISTRATION This item was consumed in the discussion of general preferred record syntax. 7. VERSION 3, DRAFT 5 Introduction: This is the fifth draft of version three. It contains only those sections that are under change or development. Discussion: Ray pointed out that agreement on the service definition is very important. It is the service definition that lays the framework for the ASN.1, not the other way around. The service definition requires a critical reading and it should not be over looked. It was then pointed out that as implementors we are drawn more to the code then to the documentation, and it is the ASN.1 that gives a concrete definition to the service description. Conclusion: The emphasis will be on the service definition. Agreements here will allow the ASN.1 to fall into place. The desire to dive into the ASN.1 will be tempered with a detailed critical reading of the service definition. 7.1 Negotiation Introduction: What does it mean for a client to turn an option bit on or off, and a target turns a bit on/off. Discussion: The topic of negotiation for services having an option bit was discussed. Specifically, what does it mean if a client turns off a bit, and the target turns it on. Does it mean the Target can support, or the Target may use the service. The general consensus was that the origin should be prepared to handle the service if the target turns it on. It was then pointed out that if the context presented by the origin does not have the needed syntaxes to implement the service and since the Target cannot add to the context, then how can the service be used. Conclusion: The issue of negotiation is left to be further defined, and there could be a distinction between client initiated services and server initiated services. The restriction that the Target refuse the association if a service is turned off and is required has been removed. This allows a more peer to peer relationship between client and server, rather than a master-slave relationship. 7.2 RE-INITIALIZATION Introduction: In view of the Abort and Release, is it redundant and can it be eliminated. Discussion: The Re-Init facility allows a client to terminate a Z39.50 association abruptly and establish a new Z39.50-association. The advantages of this service included: 1) only one PDU needed to be transfer, and 2) it explicitly informs the target to start a new Z39.50-association. This service duplicated some functionality being developed with the new release and abort services, which left the underlying A-association active. Release and abort was also discussed, but was eventually put off till the following day. Conclusion: It was decided to drop this service. The abort and release services will be negotiated. 7.3 EXPLAIN Introduction: Should explain be negotiated? How should it be described as a service? Discussion: The discussion focused on whether this is really a service or just another database provided by the server. If viewed in this way then would it be necessary to negotiate the use of explain in the init request. Conclusion: Explain would not need to be negotiated. 7.4 GENERAL PREFERRED RECORD SYNTAX Introduction: Pertained to section 3.2.2.1.5, which has changed since the last draft. Discussion: Discussion centered on the sequence of abstract syntax names. The set of database names was also explained - it is a possibly unordered sequence. All were in general agreement on the definition. Conclusion: The service definition was accepted. 7.5 RETRIEVAL FACILITY - SEGMENTATION Introduction: This topic was discussed during the second day as well as the first day. The discussion on the first day focused on whether a present response which is segmented should be confirmed. Discussion: The Present service is a confirmed service, should this mode of operation be kept when segmentation is in effect and multiple segment pdus are being sent? Should the present response pdu be sent before the segment pdus or the other way around? It was believed that the present response contains information that can only be determined after the segment requests have been sent. The notion of an aggregate present response was defined to be one or more segment requests followed by a present end request from the server. The confusion arises with having the server send requests which are then arranged into a response. It was then pointed out that the service is a confirmed service, but the requests making up the service only generate indications, not responses. Questions that were raised included: 1) at what point should a indication be sent, and 2) is there a better way to describe this service to remove the confusion, which model is better? Conclusion: It was decided that this topic needed more discussion on the list. The Present service shall remain a confirmed service, while the segment and present end pdus will remain unconfirmed - require no response from the client. DELETE SERVICE In view of concurrent operations DELETE-OPERATION was changed to DELETE_FUNCTION. 7.6 RESOURCE-CONTROL SERVICE AND ACCESS-CONTROL SERVICE Introduction: With the introduction of concurrent operations will access/resource control be used for specific operations or the entire association. Discussion: The relationship between access/resource control and concurrent operations was discussed. How resource control is used to obtain information for operations was discussed. The relationship between resource reports and trigger resource control was discussed. The diagnostics for resource report status was also discussed. Conclusion: Resource control pertains to individual operations, unless a new report format is defined. If concurrent operations is not in effect then access and resource control pertain to an active operation only. If concurrent operations is in effect, then access/resource control is not part of any operation if the reference id is not included. The resource report is used to obtain information on operations that have completed - it is an operation in itself. To gain information on an active operation the trigger resource control is used. THURSDAY 12/10/92 REVIEW Ray pointed out the change to small set-element-names and medium-set-element-names to small-set-elements and medium-set-elements. Also in the present the addition of maximum-segment-count and maximum-record-size. 7.7 SORT: Introduction: What should happen if the output result set is to be replaced and the sort fails. Discussion: There was concern that if a client indicates the same result set, or if the sort was piggy backed on a search, and the sort failed that the result set would be lost. Some preferred a partial sort, while others believed that the result set should be left undefined. The discussion then centered on the Sort-Status and the possible values this parameter could take. Conclusion: A lost or undefined result set, when a sort fails and the replace indicator is on, is completely acceptable. There will most likely be more values for Sort-Status. 7.8 SCAN: Introduction: Should DatabaseName be optional, is this service a SCAN of indexes or just TERMS, how are attributes tied to an entry, and how does this relate to Occurrence information. What should be the valid values for Scan-Status. Discussion: DatabaseName. The discussion first focused on what does it mean if DatabaseName was optional and not present. One view was that it should default to what the current Database is. It was then pointed out that this could be ambiguous, since there is no standard mechanism to set the default databasename. Another example was that the Scan would default to a thesaurus. In both cases, the Client knows what it means and it should explicitly express this to the Target through the DatabaseName. Conclusion: The field DatabaseName should be Mandatory. Discussion: Terms and occurrence count. OCLC stated a requirement for multiple attributes per term, since a term could be used in a variety of ways to access the database. There were two approaches discussed. The first was to allow the term to occur multiple times in the response. This approach was later dropped, since it would be difficult to keep positional information for the Scan. For example, if a term had 70 possible attribute combinations, and the client only asks for 20, then how would it ask for the next 20? The second approach would attach a sequence of attribute lists to each term. With this approach the occurrence count would apply to both the term and also be included in each attributelist, to give a more detailed count of how this term is used. Conclusion: For each term in the response: there will be an optional occuranceInformation, which would reflect the total occurrence over all attribute combinations; and a sequence of sequence of attribute list and an optional occuranceInformation, which reflects the count for the corresponding attribute list. The choice 4 in occuranceInformation was removed. Also the occurenceAttributes in the request was removed. Discussion: Scan Status. The Scan status was then discussed. It can be deduced that there were not enough entries at the low end, but for the high end this can not be deduced since the request could have been terminated by resource or access control. AT&T expressed a desire to have a continuation term in otherInfo if partial-4 was returned. It was generally thought that this was a useful feature, but that it still needed further thought Conclusion: The Scan status still needs further thought. It was decided that AT&T could use otherInfo to contain a continuation term if partial-4 is returned. If this looks good it may later be promoted. This brought to the discussion how otherInfo could be used, especially during the implementation phase of the protocol. Discussion: General. The ordering of the returned terms was reviewed. The question as to whether Scan replaced the Browse service was also discussed. Finally, the question as to how to specify what attribute sets the Scan was interested in was also discussed, as well as what the Target returns. There was a consensus that there could be ambiguity as to what the target returns. Two choices: 1) the target may return form any attribute set -default; 2) the target may only return from the attributes sets with in the request. Conclusion: The ordering is Target defined. There could be additional diagnostics defined for Scan. The Browse facility consists of the Scan service. An optional parameter would be added to the service, which consists of a Sequence of AttributeSetIds, if present then the service would be restricted to these, if absent then it would be unrestrictive and could apply to all attributeSetIds. 7.9 Abort and Release: Introduction: This topic was also discussed on the first day under Re- initialization. Discussion: The states when a Release could be sent was discussed. If a client could release in any state, would the release be a negotiated release, would it be disruptive. The implications as to what happens if the lower layers are aborted or lost was discussed. The IR-abort service was then discussed and the possibility of adding more information. The question as to whether a Target could issue a release request was also discussed. Conclusion: The client may only issue a Release Request in the open state. Additional Info (visible string) will be added to the IR-abort service. Along with more abort reasons: protocol error and no activity. It was pointed out that both the Client and Target share the same abort list, although some of the reasons may only be Client or Target specific. The Target is not permitted to send an IR-release request, although it may send an IR-abort request. It was held that if the target wished to send an IR-release it should be done under a Resource Request. This makes supporting the resource control service highly desirable for both client and server. 7.10 Segmentation Introduction: This was a review of the specification for segmentation. This topic was also discussed during the first day. Discussion: It was noted that Level-2 implies Level-1. A question was raised on what this actual meant and whether the meaning should go into the specification. The discussion then focused on the meaning of each type of segmentation and the possibility of reiterating these definitions into other sub paragraphs of the specification. All were in favorable agreement with the specification especially the algorithms used to provide an illustration of the procedures used during segmentation. Ray requested that others look at these algorithms to insure their correctness. A discussion of the ASN.1, pertaining to the startingFragment, then followed. There were two basic positions: 1) The EXTERNAL was required to insure that the record syntax used to transfer the record was part of the application context; 2) The startingFragment should be just an octet string, with the EXTERNAL encoded inside the octet string. With the first approach, the length of the EXTERNAL would apply to just the startingFragment, not to the whole record once all fragments were recombined by the Client. Also the application context would be maintained. The Client would know what syntax was used, and by the context sensitive tag would know that this was the startingfragment of a fragmented record. It could then either immediately present this fragment or more fragments, or even the entire record before presenting it to the user. The concept behind the second approach is that the actual record would be encoded as an EXTERNAL, thus insuring that the application context was not compromised, and then this encoding would be fragmented using the starting, intermediate and final fragment all as octet strings. The client would then pass this startingFragment to the decoder and then pass the decoded startingFragment to the decoder to start decoding the actual record. In this case the length of the EXTERNAL would be the length of the entire record not just the starting fragment. The Client could present this fragment, or wait for more fragments or even the entire record before presenting it to the user. Both approaches would require two encodings and two decodings of the record. Conclusion: Ray would look into adding more definitions to the specification for fragmentation. After a long debate it was decided that the startingfragment would be an octet string, BUT that this would still be up for review. 7.11 CONCURRENT OPERATIONS: Introduction: This topic was a review of the specification for Concurrent Operations. Discussion: There was favorable acceptance of this specification, with one exception. This was the implied support of named resultsets. Several held that this was an unnecessary restriction and should be lifted. It was also believed that a diagnostic should be added if multiple operations access the same result set. Some thought that this could be completely reasonable while others held that this could be an error. Conclusion: Named result sets need not be in effect for concurrent operations. A new diagnostic will be added if a target does not support multiple concurrent access to a result set. 7.12 ELEMENT SETS: Introduction: This was a review of the specification for Element Sets Discussion: This topic generated lots of discussion, specifically on definitions and relationships between elements, element sets, record syntaxes and database records. It was generally conceded that element sets can be associated to a specific record syntax, to a particular database or even to a combination of both. A question was raised on the possibility of combining preferred record syntax into element sets names, but the majority concluded that this needed further study. There was a need expressed to define what an element is and how it relates to the other definitions. Several held that this was just too basic to define while others held that it was required to build a sound understanding of the protocol. Conclusion: There will be a definition of element. Definitions should be submitted to Ray. Two were submitted during the discussion: "An information item defined in the abstract syntax of the record". "A component of an abstract syntax record". Digression: Sort: SortKey: missing data value - should it be defined as external, octet string? The missingValueData in the SortKey may become a choice between INTEGER, OCTETSTRING, and EXTERNAL. This will go on the list. The discussion then led to what happens to a result set when a sort is piggy backed on a search. Should there be upper bounds on the number of records to be sorted? Should sort status be included in the response? What happens if the set is only partially sorted, are the records presented, if so are they to be sorted or unsorted? Or is the result set lost? Does just the sort fail or the entire search? Is the piggy back searched needed for version 3? There were concerns on the complexity that the piggy backed present and sort add to the search. Can sort be rolled entirely into search - this was met with a definite NO. 8 EXTENDED SERVICES: Introduction: This service has under gone a complete revision and was presented to the group in its new form. Discussion: Denis introduced this topic. He pointed out how it differed from previous versions, specifically how only one database would need to be supported. Extended services would be distinguished by a different record type, and each would be identified by a specific name (like a userid). The Create service was explained. The response from the target would only indicate whether the request was syntactically correct and that at some future time the target would act on the actual request. There is no guarantee as to when the request will be operated on. A target could delete a request at any time. There could be an option to get results back in the Create response, but this is totally non guaranteed. The important points were that the model did not place any requirements on when the target would actually created the request, and that these requests could live for a relatively long time, as defined by the target. By searching the EXPLAIN database a client could determine what type of extended services a target supported by the record syntaxes support for this extended services database. Questions raised by the group were the stability of this approach, did the specification really mean record syntax or element set names when referring to the different extended services. It was thought that indeed this approached was stable, and could support newly defined extended services. The question on whether the specification dealt with record syntaxes or element set names was debated heavily, with the general consensus that it was element set names. It was also pointed out that this service assumed support of multiple named result set s. Conclusion: This approached to extended services was accepted as the best solution so far. However, it was generally agreed that some of the externals needed to be developed and that a service definition also need to be defined. Denis accepted the responsibility to define the service definition. Friday 12/11/92 NEXT MEETING SCHEDULE The next meeting is to be held on April 14-16/93 in Washington D.C. Another meeting was set to be held in St. Louis for July 7-9/93. A tentative meeting to be held in Ottawa was also schedule for sometime in October, possibly the 4, 5, and 6. 9 APPLYING ATTRIBUTES TO RESULT SETS Introduction: Just as attributes are associated to a term, is there a way to associate attributes to a result set? What are the semantics, and how does this relate to proximity. Discussion: AT&T expressed a desire to associate attributes to a result set, although this can be done using two queries it is expensive. The model of the result set is that it contains all relevant information needed to access the record. There was support from others for doing this, basically it entails restricting the result set with additional attributes. This is supported in CCL and can it be supported in a query? A discussion of the semantics of this followed. It is more than searching a result set, because the second set of attributes may not have a term. One approach discussed was to make the term optional, thus allowing the attributes to be moved across the boolean to the result set, in effect limiting the result set by the attributes. However, this generated a lot of controversy. In making the term optional, the semantics of the search are changed, as well as the semantics of the operator. There was a lot of different philosophies as to what these semantics would be. One suggestion was to make the term NULL, but this also met resistance. Another approach was to allow the result set to be part of the operator, thus allowing attributes to be tied to the result set. Again the semantics of this was discussed with varying views. There was a general consensus that restricting result sets through attributes provided additional functionality, and perhaps this could be developed for version 4. It was pointed out that this is exactly how a major portion of searching is done in current systems and that it should be looked into now. Was this a modeling problem? It was thought to be a modeling problem with the search, not the result set. One opinion was that the model of an attribute is an inherent quality of a term plus attributes and that they could not be separated. The result set is a representation of a query (perhaps several), thus this operator becomes not an operator on a result set but on the query that created the result set because you can't evaluate it unless you tie the query back to the result set. Several questions raised during the discussion: is this similar to proximity; could it go into type 101; what was the general case; since the result set is a representation of a query, does the query then become an operator; how do you distribute the attributes across the query or result sets; was this just a form of short hand for a new query? Conclusion: It was decided that there should be a sub group to define the semantics of applying attributes to a query. A first draft for the semantics for a restrictive operation was presented: (FIELD op VALUE) / X ==> (FIELD op VALUE) and (X op VALUE) (q1 and q2) / X ==> (q1 / X) and (q2 / X) (q1 or q2) / X ==> (q1 / X) or (q2 / X) (q1 and-not q2) / X ==> (q1 / X) and-not q2 where 'FIELD' is a set of attributes, 'op' is a relational operator; 'VALUE' is a term; '/' is the restriction operator - in essence 'and'; 'X' is another set of attributes; and 'q1' and 'q2' are two queries. In RPN terminology: q1 X /, where q1 is the first operand, X is the second operand - consisting only of attributes, and / is the operator. It was also suggested that since the current model of result sets only addresses retrieval, there could be additional modeling information applied to the type 101 query to support these semantics and a statement could be made that some implementations may not be able to support this. This item is still open. Discussion: Proximity There were three objections raised concerning the current proximity query: 1) the meta data is at the record level, not at the result set level, 2) Norway simply does not want proximity between sets, and 3) Canada claims that the proximity operator is not a binary operation, since it has underlying parameters associated to it. Canada claims that comparisons between sets can only be made on the basis of the elements comprising the sets, that is the existence of an element in each set being compared. Thus A and B becomes A intersect B, A or B becomes A union B, and A not B yields all elements in A that are not in B. Proximity on the other hand, operates on the elements within each set - like, how does element a, from set A, relate to element b, from set B, which is more than just the existence of these elements within the sets. Canada has a method to resolve proximity between sets. Their claim is that since proximity acts on records not on sets then proximity should become an operand with two terms. Conclusion: Although this is different than applying attributes to a result set, the solution to one could apply to the other. Eric and Bob will summarize, Ralph will take a crack at the model, and may also include ranking. Joe Zeeman will post the Canadian solution to proximity. This item is still open. 10 INTEROPERABILITY AND USER AUTHENTICATION Introduction: How to make systems secure while insuring interoperability. Discussion: AT&T wants some form of agreement on the format to be used in authentication. Will it be based on Access Control, should it be based on Andy Bensky's and Eric Bivona's paper? Should Authentication be EXTERNAL rather than ANY. There were three forms of authentication identified: 1) Initialization authentication, 2) Access authentication, and 3) on the fly authentication. Concerned was raised that the group does not try to re-event algorithms, that work being done by IETF on common authentication technology, and kerboros be used. It was agreed that only formats will be defined, not authentication algorithms. The various security levels identified were: 1) Copyright, 2) kerboros, 3) userid/password in the clear, 4) userid/password encrypted, 5)access control format for a challenge (random number), 6) general access challenge for accounts with some sort of structure with a human string, and 7) validate software. Conclusion: The issue of authentication has been reactivated, with Eric, Denis, Les, and Ralph taking the lead on the issue. Denis will receive requests for additional security levels. Idauthenication will be profiled as EXTERNAL. 11 FREE TEXT SEARCHING Introduction: Is there agreement on the way that free text input can be sent to the server, so the server can do its thing to send back the set of documents. Discussion: Was the concept id created for this? In the profile, if doing free text conceptual based searching, then send the string as concept id with a structure of word list. Concept reference is used for document id in relevance feedback. Conclusion: Nothing is said as to how the server performs this. The client may take free text from the user, send it to the server as concept text, the server does something to create a result set. This is used for the body of the text, where it may have structure such as title, chapter, section ect, it searches across parts of the document. Concept searching searches across all parts of the document, and the words making up the concept may not even be part of the document. 12 EXPLAIN BASED DISPLAY LANGUAGE Introduction: A client may need to know how to display a record. Discussion: Basically the client will ask for a record from EXPLAIN that will help the server to learn how to display records. There seems to be many different ways to perform this all of which are valid, through raw ASCII, ElementSetNames, or EXTENDED services. Ralph wanted an ASCii record syntax to be used for the display language, and then using ElementSetNames to further refine the syntax - such as line terminators. Les, on the other hand, wanted different record syntaxes - raw ascii, display ascii. Conclusion: It was generally accepted as a good idea to include these in EXPLAIN. There was agreement that a record syntax for an ASCII description needs to be nailed down on the list, Ralph will post the first attempt. Bob will post his display language and John may also post something that will allow the client to determine the record layout. ASIDE Les would like to expand the ASN.1 for EXPLAIN to define the attribute sets. He would like to dynamically discover information about the attribute set: attribute set id; for this use attribute these are the valid values for this database; for this attribute this is what it means. It is not so much on how to use the set - searchable attributes, but rather what the set is - information about the attributes. This brought up the need for an authoritative EXPLAIN service. 13 MULTIPLE RECORD RANGES ON PRESENT Introduction: Berkeley introduced a desire to request non contiguous records in a present. Discussion: This was received with favorable acceptance. The ordering of the returned records was discussed - ascending order, or order given by client, or target defined. Can this be done with concurrent operations - it was thought that this required unnecessary over head. Does it require an init bit? Since this is a new requirement it should have further refinement. Conclusion: This item is to go to the list and will be brought to discussion at the next meeting. John and Ray will help to refine the specification. 14 MARC CONFORMANCE Introduction: With Servers returning non bibliographic records in MARC format is there a standard way to build the record. Discussion: Several services seem to be doing it now - ERIC, MEDLINE, IAC and WILSON. The discussion centered on building the leader for a non catalogue record. Questions raised included: are there acceptable values to put into fields and subfields that have no corresponding value in the record, if so are blanks ok; are fixed fields required, what fields are required; is the vertical bar valid for every field? Conclusion: Sarah and Michelle volunteered to come up with the minimal required fields for IAC. 15 INFO1 and ES1 Introduction: Can the summary record be replaced by INFO1? How INFO1 uses attributes. Discussion: The discussion first focused on whether the summary record could be replaced by INFO1. Currently only FCLA, NOTIS, RLG, and Software Kinetics are using, or plan to use, the summary record. The new version of WAIS seems to be moving towards INFO1 which may be reason for supporting at least the generic subset of INFO1. The INFO1 record contains generically tag fields and non generic tag fields and through the use of ElementSetNames only the generically tag names could be returned. Conclusion: Since it was generally held that INFO1 was more flexible, the possibility of replacing summary record will be explored. Discussion: John then explained how INFO1 uses attributes to define the tags of an INFO1 record. The use of the INFO1 attribute set combines the search with the retrieval through the reuses of the tag space. The generic tags are known, while the dynamic tags are known through EXPLAIN or through some table. With the approach given, if an INFO1 tag has a corresponding value in the attribute set, then the use attribute defines what the tag means. At first this was met with skepticism, most did not like the idea of combining all possible attributes under INFO1, the addition of another maintenance agency, and the implicit link between search attributes and tag elements. But as the debate progressed it gained popularity. The concept of having the attributes define the tagging being used in the INFO1 record seemed to be accepted, but the idea of having an integer replace the OID for the attribute set id met tough resistance. Basically, INFO1 would use the attribute set id (elementTagType) to reserve a numeric name space to be used to tag the INFO1 record. This would guarantee that certain tags be unique over all possible tags, which was a requirement of some implementors. The INFO1 record along with the totality of the available tag sets becomes the abstract syntax. The relationship between tag types and attribute sets ids was discussed. This relationship could be a one to one mapping, or the mapping could be disjoint, or combination of both. This one to one implication drew some criticism, since several attributes could map to the same field in a record. Cliff mentioned that the attribute sets available were actual a vocabulary used to define the fields in a database and their relationship to various search attributes. These two sets, the tag type and attribute set, although conceptually separate could have overlapping elements. After debate on the values for these identifiers it was suggested that these take on the same value. Ralph stated that this mechanism of discovering the meaning of tags and applying tags to attributes sets applies equally well to raw BER encoded records without the over head of INFO1 - INFO1 does other things that than just purely tag fields. Conclusion: Although this mechanism of defining the tagging was accepted by most of the group, the addition of another maintenance agency, the inclusion of all attributes into INFO1, and the replacement of an integer for an OID met a large opposition. It would be cleaner if the attribute sets were left as is, and the elementTagType became an OID. Thus, as new attributes sets are created, once they become registered they would automatically reserve a tag space in an INFO1 record. It was also suggested that there could be a global elementTagType and an optional elementTagType in each tag, which could then be used in a similar manner as the attributeSetId in a query. This item remains open, and it is left to John to decide what to do. ZIT ISSUES: Cliff went through some ZIT specific issues: demos, his document on questions and answers - which he will try to update in time for ALA in Denver, attribute mapping between different systems, and the display of a record in a client. The following items were not discussed due to time constraints. 1) Requesting items using retrieved pointers. 2) Template-based EXPLAIN. Deadra Harvey Terry Sullivan