======================================================================== Date: Mon, 2 Sep 1991 18:25:05 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" Comments: Warning -- original Sender: tag was brewster@QUAKE.THINK.COM From: Brewster Kahle In-Reply-To: dml%MOZART.ESL.COM@pucc.PRINCETON.EDU's message of Mon, 26 Aug 1991 18:15:32 PDT <9108270123.AA00960@Early-Bird.Think.COM> Date: Mon, 26 Aug 1991 18:15:32 PDT From: dml%MOZART.ESL.COM@pucc.PRINCETON.EDU Where does a person find the definitions of the various search response RecordSyntaxes? Do any of the RecordSyntaxes defined in Appendix E support returning text in an SGML tagged form? Brewseter Kahle -- how are you planning to have WAIS return document bodies when you convert to Z39.50 V2? As the result of a search. It is a bit kludgy but it is somewhat within the spirit of the spec. We need to be able to transmit parts of documents. Thanks for the help on such simple stuff. --Denis Lynch, ESL Inc. ======================================================================== Date: Mon, 2 Sep 1991 22:36:28 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch The attached is a long-promised replacement to Appendix F of the Z39.50 draft, redoing Resource Report Format bib-1. I would like to put a brief review/approval (hopefully) of this on the agenda for the implementor's group meeting. Please note that I have punted on units for the COST parameter and specified US dollars; if there is some preferred way of handling assorted currencies, I am not familiar with it and would welcome suggestions, since this issue will undoubtedly have to be addressed before resource control moves into the ISO 10162/ 10163 addenda in preparation. The changes here are to (1) add units, and (2) add one more value to the list of types. Clifford Appendix F: Resource Report format Bib-1 This appendix is part of the standard. This appendix defines the resource report format bib-1. The object identifier for resource report format bib-1 is defined and registered in Appendix A. When the value of ResourceReportId (within ResourceReport in the auxiliary definitions for the Resource Request APDU) equals the object identifier for this resource report format, then EstimateType (within Estimate) takes values from the type column in the table below. Type Meaning 1 estimate of number of records in current (incomplete) result set for search 2 estimate of number of records that will be in the result set for search if the search completes 3 estimate of number of records in current (incomplete) set of records to be returned on PRESENT 4 estimate of number of records that will be in the set of records to be returned by PRESENT if PRESENT completes 5 processing time (in .001 CPU seconds) used by this operation so far 6 estimated total processing time (in .001 CPU seconds) that will be used by this operation if it completes 7 estimated processing time used by this association (in .001 CPU seconds) 8 estimate of cost for this operation so far (in US cents) 9 estimate of cost for this operation if it completes (in US cents) 10 estimate of cost for this association so far (in US cents) 11 estimate of elapsed time for this operation if it completes (in .001 second units) ======================================================================== Date: Mon, 2 Sep 1991 22:46:39 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch Subject: attrib lists Question: has the latest (and greatest) bib-1 attribute set been posted to the list? I am trying to go over a bunch of details carried foward from the last meeting prior to this one and it would be very useful to have the latest version to work off of. Want to make sure I have the correct base. Thanks Clifford ======================================================================== Date: Mon, 2 Sep 1991 23:47:52 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch A question on the language attribute; the attribute set specified code-language (similarly for code-institution, code-geographic area, etc). do we need to (1) specify the source of these codes for each attribute, and (2) perhaps add a non-coded form of language (and the other attributes) that would allow a client to pass full-text (eg ENGLISH, SPANISH, etc rather than 3-letter codes or whatever they are)? Clifford ======================================================================== Date: Mon, 2 Sep 1991 23:39:23 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch Question for the group. Does it make sense to attach a document such as the one that LC prepared on Attribute set bib-1 to the Version 2 spec as an informational appendix, or to try to work some of this material into appendix C directly so that the use of attribute set bib-1 is better defined? Also, what is everyone's understanding of where we ended up on proximity -- version 2, version 3, or still under discussion? Clifford ======================================================================== Date: Mon, 2 Sep 1991 23:16:37 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch Subject: segmentation The following is a set of proposed extensions/changes to Z39.50, codifying what I believe were agreements in principle at the last Implementor's group. I would like to review these as an agenda item, and confirm them. Clifford Segmentation facilities for large records There is a clear need to be able to segment large records on a present operation (either a pure present or a "piggyback" present that is part of a search). There are two solutions proposed. The first is a CLEAN solution, which would have to go into Z39.50 Version 3; the second is a KLUDGE solution which works with Z39.50 Version 2 (we gotta have it now, at least for WAIS and for folks moving fulltext or images) which has an obvious upwards compatibility path for version 3. Version 3: Add to the PRESENT APDU (and also the SEARCH APDU for piggybacking) an additional complex field, called SEGMENT. The SEGMENT field has the format segment-type: one of "BYTES", "LINES", PARAGRAPHS", or "CHUNKS" (obviously extensible by defining more values; LINES, PARAGRAPHS, and CHUNKS are interpeted by the SERVER and the protocol doesn't specify exact algorithms for counting such things within a record; this is obviously application dependent. Clearly, we'd use encoded values for these in the ASN.1, not the literal strings. segment-start starting value (numbered from 0) segment-end ending value. If no ending value is specified, the default is the end of the record or as much of the record that will fit in the APDU, whichever is smaller. The segment-end value probably needs to be sent back in the SEARCH-RESPONSE and PRESENT- RESPONSE APDUs so that the client can figure out what went on; when it appears, it would apply to the last (or only record) transmitted back in the response APDU. It may also be advisable to suggest that servers supporting one or more of these segment-types also support an addtional element set name of SIZE-BYTE, SIZE-LINE, etc which sends back records consisting of a single integer giving the size of the record in the result set. A transfer syntax for this is pretty trivial. For Version 2 The ELEMENT-SET-NAME field is visible string. We could define a special kind of element set name that is really a structurd string containing both the real element set name and the segment definition in the form: KLUDGE1/elementsetname/segmenttype/segmentstart/segmentend/ where elementsetname is the real elementsetname, segmenttype is B, L, P or C and segmentstart and segmentend are ASCII format numbers (ie not binary numbers) giving the start (from 0) and end boundaries. ======================================================================== Date: Tue, 3 Sep 1991 00:31:27 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch Subject: cancelling searches Following up on another writing assignment from previous implementor's group meetings.... An extended resource control function. These extensions meet two requirements: (1) for a client to find out session cost to date (and perhaps cost of active operation), and (2) to permit a client to cancel an active operation. Question: should these be added in version 3, or packaged into version 2 since they won't cause any further compatibility problems with the ISO versions, which don't have resource control in the first place.  comments? Note that these changes make a terrific mess of the existing state tables. Add new APDUs: 1. ABORT CURRENT OPERATION APDU this can be sent by the client at any time except when an INIT has been sent and an INIT RESPONSE has not yet been recieved, or when a RELEASE or ABORT (or CLOSE, if we add one in Version 3) is in progress. If sent when no operation is pending, the request is ignored (this probably is needed to cover various sequencing problems that might take place). If sent while a DELETE is pending (eg DELETE response is pending) it is ignored (interrupting a DELETE is asking for trouble). If sent when a RESOURCE CONTROL is pending from the SERVER, it is also treated as a RESOURCE CONTROL response in addition to its basic function of terminating the active operation. If sent while a SEARCH or PRESENT request is executing on the server, then the server will terminate the outstanding SEARCH or PRESENT at its earliest convenience and set the search status or present status to "aborted", a new value. If the ABORT APDU has specified that partial resuts are to be retained, then result set status may be set to NONE, SUBSET, or INTERIM just as in other cases. If the ABORT APDU specifies that a partial present is desired (when a present request is pending) then the present-status can be the new value partial-6, indicating that not all expected records can be returned because the request was prematurely terminated by the client. (It may be possible to use partial-3 for this purpose, but it may be clearer to have two distinct values). Parameters of the ABORT APDU: Reference-id (optional; should be the same as the reference ID of any pending APDU if it is used, however -- this avoids problems with resource control.) partial result set to be retained -- yes/no partial present requested -- yes/no 2. RESOURCE REPORT REQUEST Simple proposal: this can be sent whenever there is no pending operation. It triggers, as a response, a resource control report response APDU from the server containing a resource report. Parameters: RESOURCE REPORT REQUEST: reference-id any value RESOURCE REPORT RESPONSE reference-id same value as in the triggering resource report request resource report complicated proposal: the RESOURCE REPORT REQUEST can also be sent when there is an active present or search apdu, in which case it triggers the server to send a RESOURCE CONTROL message back to the client. This RESOURCE CONTROL APDU is processed normally, ie the client generates the usual RESOURCE CONTROL RESPONSE. questions: go with the simple or complicated version? Also, should this be a separate function package in the INIT, or part of basic resource control? Clifford ======================================================================== Date: Tue, 3 Sep 1991 09:29:01 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Joe Zeeman Subject: Re: language codes In-Reply-To: ; from "Clifford Lynch" at Sep 2, 91 11:47 pm > > A question on the language attribute; the attribute set > specified code-language (similarly for code-institution, > code-geographic area, etc). do we need to (1) specify the > source of these codes for each attribute, and (2) perhaps > add a non-coded form of language (and the other attributes) > that would allow a client to pass full-text (eg ENGLISH, > SPANISH, etc rather than 3-letter codes or whatever they are)? > Clifford > I had always assumed that these codes would be implemented as the MARC codes. I would have thought that specifying which code sets would be used is a profiling matter. Passing full text is only useful for those target systems which can translate between code and full (English) name. It strikes me that a USE attribute of code-language is probably incorrect: it should be "language-of-text", and have a structure attribute of "coded info" or such-like; then the same use attribute could be used with different structure attributes to achieve something like Clifford has suggested. -- />----------------------------------------------------------------<\ \ Joe Zeeman / / Software Kinetics Ltd \ | 65 Iber Road | \ Stittsville, Ontario voice: (613) 831-0888 / / Canada K2S 1E7 fax: (613) 831-1836 \ \>---------------------------------------------------------------- Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" In-Reply-To: Message of Mon, 2 Sep 1991 18:25:05 PDT from Re: Question from Denis Lynch, ESL, Inc. The result record syntaxes are not available, to the best of my knowledge , in any one place. From our point of view, the most important one is USMARC which is available from the Library of Congress. Ask Ray or Larry at the meeting for more info. The actual architecture of the USMARC record is a NISO standard, Z39.2. It is available from NISO. If you have access to a library, there is a good chance you can find both docuements there but probably not in the general collection. You may have to convince a back-room type to let you look at it. ======================================================================== Date: Tue, 3 Sep 1991 10:03:09 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ralph LeVan Subject: Re: segmentation I don't think your proposal handles heirarchical data (such as marc records) very well. Trying to map such data to a flat structure that can use relative offsets is cumbersome at best. We're transmitting full text of books and articles over z39.50 here, and needed a mechanism that would allow us to specify views on the records that gave starting and ending points, maximum record lengths that would be honored by having the target progressively transmit pieces of the record, allow us to specify which fields of the record to transmit and/or which levels of the heirarchy to transmit. I brought syntax for this to the last meeting, but we never got around to it. (I didn't make it an agenda item.) The mechanism assumes that the records are ans.1 encoded. The only sticky point as far as z39.50 is concerned is the progressive transmission, which violates the simplistic state machine model of a user session, as the origin will often want to interrupt the progressive transmission to initiate a new request. Ralph Ralph LeVan Internet: rrl@rsch.oclc.org Online Computer Library Center UUCP: ...!saqqara!sppy00!rrl 6565 Frantz Rd, Dublin OH 43017 Phone: (614) 764-6115 ======================================================================== Date: Tue, 3 Sep 1991 10:16:24 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: listserv problems? Cliff Lynch has reported some problems in posting mail to Z3950IW. I believe these may be due to an impolite node between him and the listserv but just in case, if you do not receive notification from LISTSERV@NERVM that your message was distributed in what you believe to be a "normal" time period, send me a private email. Of course, if it is a net problem and not a listserv problem, since i am at the same node as the listserv, I will not get the message. ======================================================================== Date: Tue, 3 Sep 1991 10:24:30 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Re: segmentation In-Reply-To: Message of Tue, 3 Sep 1991 10:03:09 EDT from Ralph, Is this an agenda item? ======================================================================== Date: Tue, 3 Sep 1991 10:23:51 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ralph LeVan Subject: Re: cancelling searches I like the abort request. We have much the same thing here. I think the complicated resource request is much more valuable. Ralph Ralph LeVan Internet: rrl@rsch.oclc.org Online Computer Library Center UUCP: ...!saqqara!sppy00!rrl 6565 Frantz Rd, Dublin OH 43017 Phone: (614) 764-6115 ======================================================================== Date: Tue, 3 Sep 1991 10:10:34 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Peter Ryall Subject: Re: Re: language codes In-Reply-To: Mail from 'Joe Zeeman ' dated Tue, 3 Sep 1991 09:29:01 EDT I agree with Joe on a more explicit USE attribute such as 'language-of-text', as we are already encountering situations in our international business where we must provide local language entry of search connectors, attribute names, & even attribute text in some cases, as well as local language presentation of all non-full-text data & user prompts/error messages. Thus this distinction would help disambiguate the different types of information being accessed from the Target. We are not yet in the business of doing real- time full-text translation, however, some of our European partners are quite interested in providing this service locally to their users as the data is being prepared for presentation. ======================================================================== Date: Tue, 3 Sep 1991 12:32:42 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: agenda I will be leaving for beautiful Ohio on Thursday night to visit family before the ZIG. If possible, please have all agenda items posted before noon tommorrow (Eastern time) to give them time to get to me (oh, great net, please expidite my mail!). I will bring copies of the agenda containing those items recieved by 3 pm Thursday. Any others can be added at the meeting. The items I have currently: 1. Draft 4 of Z39.50 version 2 (Denenberg) 2. Profile documents: (Denenberg) - SR PICS Proforma - Z39.50 PICS Proforma - ZIG PRL (Profile PICS Requirements List) 3. Z39.50 Enhancements tracking mechanism (Denenberg) 4. Maintenance Agency registration of implementors (Denenberg) 5. Relationship of ZIG to NIST OSI Workshop (Denenberg) 6. Review of Resource Report Format bib-1 replacement (Lynch) 7. Proximity vis-a-vis Result Set Models (Lynch) 8. Local Record Syntaxes (Lynch) 9. Review of Proximity Operators in ASN.1 (Hinnebusch) 10. code-language vs. content-language USE attribute (Lynch, Zeeman) 11. Persistent result sets (Ryall) 12. Periodic search service (Ryall) 13. Financial/news attribute set (Ryall) 14. Z39.50 PDUs directly over TCP (Stovel) 15. TC46 work on Explain and Browse (Zeeman?) 16. Browse (Randall) 17. Explain (Randall) 18. Segmentation facility (Lynch) 19. Abort current operation (Lynch) 20. Resource report request (Lynch) 21. Profile restrictions of data element lengths (Sullivan) 22. Test bed (Greenfield) I am open to changes in the order. --mark ======================================================================== Date: Tue, 3 Sep 1991 12:47:53 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Re: segmentation In-Reply-To: Message of Mon, 2 Sep 1991 23:16:37 PST from The response APDUs will also need a flag indicating if the defaulted end-of-segment was due to end-of-record or PDU-size-exceeded. On rare occasions, both could pertain in which case comparing the size against the PDU maximum would not suffice. ======================================================================== Date: Tue, 3 Sep 1991 12:50:59 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Re: cancelling searches In-Reply-To: Message of Tue, 3 Sep 1991 00:31:27 PST from Cliff, Does receipt of a resource control report request cause suspension of the operation until the resource control response is recieved? If I cannot suspend, does this mean I do not offer resource control? ======================================================================== Date: Tue, 3 Sep 1991 10:27:43 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "John A. Kunze" Subject: agenda In-Reply-To: "Mark Hinnebusch, FCLA"'s message of Tue, 3 Sep 1991 12:32:42 EDT <9109031649.AA02828@nettlerash.berkeley.edu> I'd like to add one agenda item concerning nomenclature: 23. Identifying implementation types. Background ---------- Many of us are not actually doing a Z39.50 implementation over a full OSI stack, at least not in the short term, and in the very short term many of us are also making compromises with other layers and services. I'd like to see some new names to help identify these mutant forms. For example, "Z39.50-ZT" or just "ZT" This could be Z39.50 over TCP/IP. "Z39.50-ZT-PS" or just "ZT-PS" This could be ZT minus Presentation and Session layers. "Z39.50-ZTSR-PS" or just "ZTSR-PS" This could be ZT-PS minus Resource and Access Control (a la SR) "Z39.50-Z" or just "Z" Full Z39.50, useful in the context of the above terms. I think these are some common variants, but I'm sure there are others. We at UCB will be working with some servers using "ZTSR-PS" for the short term, but will also have "ZT" capability in the medium term, and full "Z" capability in the long term. -John ======================================================================== Date: Tue, 3 Sep 1991 10:38:14 -0700 Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark H. Needleman" Subject: bib 1 Hi We are looking for the up to date bib1 attribute list. We rummaged on the think.com server but couldnt find it. Does anyone remember where it is or waht zig number it is. Also as a suggestion it would be nice to have a file out there called zig-index which tells what each of those files are Mark Needleman ======================================================================== Date: Tue, 3 Sep 1991 10:53:53 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Jack_Greenfield@NEXT.COM Greetings, all. Here is another item for the agenda... Sometime after this upcoming ZIG meeting, but before the next one, we will be in a position to start interoperability testing in earnest. At present, however, the only vehicle for interoperability testing afforded by the ZIG is the opportunity to make ad hoc arrangements with other implementors. While this is certainly valuable, I would like to propose a second vehicle: a formal interoperability test bed sponsored by the ZIG. Several years ago, I had opportunity to observe the test bed that supported the PDES protocols developed under the auspices of the CALS initiative. This project is a compelling precedent for interoperability test beds. In practice, it proved to be more than a vehicle for testing, and effectively promoted the rapid and wide- spread acceptance and deployment of the PDES protocols by the target community. I think this project could serve as a model for a Z39.50 test bed. To make this happen, we would need to: (1) recruit a management agency; (For now, since we are relatively few in number, this would not be an overwhelmingly large job, so hopefully someone will be both willing and able to volunteer.) (2) compile a directory describing the participants; (For each entry, the directory would describe, at a minimum, protocol stack(s), addressing, connectivity, and databases available.) and (3) define a test suite to be used in demonstrating interoperability. (This could be a massive undertaking, if carried to an extreme, but I believe that something far less ambitious than an exhaustive test suite could prove quite effective.) The management agency would be responsible for collecting and disemminating the results of tests, and for maintaining the directory of participants. Unfortunately, the management agency cannot be NeXT. Lest this be construed as laziness on the part of the author, let me point out that I am currently the only person at NeXT working on Z39.50 and WAIS, and that I am concurrently responsible for several other projects, including the native retrieval machinery (all the way from the query language and document model down to the transaction manager and access methods), a distributed platform retrieval architecture, and the integration of that architecture with the rest of the system software. J. ======================================================================== Date: Tue, 3 Sep 1991 11:45:21 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Andy Bensky Subject: Re: segmentation > > Clifford > > Segmentation facilities for large records > > There is a clear need to be able to segment large records on > a present operation (either a pure present or a "piggyback" > present that is part of a search). There are two solutions > proposed. The first is a CLEAN solution, which would have to > go into Z39.50 Version 3; the second is a KLUDGE solution > which works with Z39.50 Version 2 (we gotta have it now, at > least for WAIS and for folks moving fulltext or images) which > has an obvious upwards compatibility path for version 3. > Our implementation here at Sun has always had this requirement and we have adopted a simple solution. Each APDU, or at least Search and Present responses, have a finality flag. If the number of records in the response is more than 1 then each response APDU will contain an integral number of records. Additional records will be sent in the next Response APDU with the same Reference-Number. In the case where a single record exceeds that Max-Record-Size and/or Max-Message-Size, as in a file transfer where only a single record was requested (the file) and it can easily exceed all size constraints (files can be >100K or more), the Responses will contain Max-Record-Size bytes which can be put back together by the client. The advantage to this over the other methods proposed is that it does not require that the client explicitly issue an additional request for each segment. If a user is waiting upwards of 1/2 hour or more for a file to download the extra time consumed by an additional request/response round trip, not to mention server processing time, could be frustrating and possibly unacceptable. Combine this capability with the Cancel transaction Cliff describes, which is almost identical to the Cancel transaction we have designed, and the protocol is more functional and flexible. Of course, both segmentation options Cliff describes provide even finer flexebility and are excellent ideas. If memory serves we had made some preliminary decisions at the last ZIG to use KLUDGE1/elementsetname/segmenttype/segmentstart/segmentend/ for now. If Version 3 allows us to adopt a better defined method that would be allow even more interoperability and I would very much be in favor of it. In the meantime we are allowing multiple responses to a request using the finality-flag. Unfortunately I will not be able to attend the ZIG meeting at OCLC next week due to our strict implementation schedule and lack of resources to get it done. I hope to see you all again after Version 2 comes out to begin discussions for Verson 3. andy bensky Sun Microsystems ======================================================================== Date: Tue, 3 Sep 1991 14:32:33 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Re: bib 1 In-Reply-To: Message of Tue, 3 Sep 1991 10:38:14 -0700 from There had been an index on THINK.COM ftp server. Thinking Machines has reorganized their ftp directories and it seems the index got lost. I will send it asap. To get to the ZIGs, do: cd wais cd z3950 dir --mark ======================================================================== Date: Tue, 3 Sep 1991 14:55:12 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: ZIG INDEX I sent the file ZIG.INDEX (all upper case) to the THINK.COM ftp server. Again, new directory structure is: cd wais cd z3950 get ZIG.INDEX ======================================================================== Date: Tue, 3 Sep 1991 12:33:11 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch With regard to Mark H.'s question about whether a resource control report request causes suspension, I would presume that this would be up to the server; the server could indicate in the resource control message that was generated whether processing was suspended or not until a resource control response was recieved back from the client just as it does in the current version of the protocol. A well-behaved server probably would not suspend in most cases when processing a resource control report request, unless it was getting ready to generate a resource control message anyway cause of the amount of resources that a search was consuming. Certainly, ability to suspend is not a requirement in supporting either the current resource control facility or the proposed extensions. Clifford ======================================================================== Date: Tue, 3 Sep 1991 12:36:51 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch Subject: LeVan on segmentation In regard to Ralph's comments on segmentation. It would be useful if Ralph could post his proposal so we could have some time to think about it prior to the upcoming meeting. It may well be that there are multiple appropriate mechanisms. My sense is that his approach would work well with highly structured objects. There is still a need to segment large, unstructured objects such as bitmapped images. The issue of progressive transimssion is a very interesting one that I would like to explore further. Clifford ======================================================================== Date: Tue, 3 Sep 1991 12:44:49 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch Subject: languages and codes Regarding comments from Peter Ryall and Joe Zeeman on language codes. If I am understanding the comments correctly, there are really multiple issues on the table. One is the definition of the language search attribute as language of content of the material (particularly for fulltext databases) Another is the problem of search keys that can be specified in multiple languages -- ie find documents on subject X where X is a term in French as opposed to English. A third is the possiblity of structure attributes for coded-value (eg language names in MARC codes) vs uncoded value (eg english-language). If we go with coded-value,as Joe suggests (and I think this is a very nice clarifying concept) then will bib-1 attribute set need to indicate what the code set is the coded-value structure attribute is used with a given access point? Joe suggests this is a profile issue. I am very concerned that we rely on profiles to the minimum extent possible, since I am not optimistic that a profile approach scales well to a situation where clients and servers need to dynamically interoperate without prior out-of-band agreements, which is the target environment I see us designing for. I would much rather register code sets and indicate which code set is being used, or, even better, fix code sets for specific attributes in the bib-1 attribute set definition. In any event, have I got the issues separated out correctly, or have I misunderstood Peter and/or Joe? Clifford ======================================================================== Date: Tue, 3 Sep 1991 16:45:08 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Joe Zeeman Subject: Re: languages and codes In-Reply-To: ; from "Clifford Lynch" at Sep 3, 91 12:44 pm Clifford's analysis is spot on (although there are probably even more language-related issues yet to be thought of). The bib-1 use attribute code-language derives from the language codes kept in MARC records in fields 008 and 041, which encode various languages associated with the item being catalogued (e.g. language of the item, original language if this is a translation, etc.). The codes are published in an appendix to the MARC format, and consist of three-letter, reasonably mnemnonic, codes, like eng for English and bla for Blackfoot. I don't know if they correspond to any ISO or ANSI standard (it doesn't say in the CanMARC standard, which is all I have to hand). I think it is implicit that the designers of the Bib-1 attribute set intended code-language to be that derived from the MARC record, and the easiest way to proceed is probably to make this explicit. It would be useful if the full-text people could clarify what kinds of language searching/specification facilities are or ought to be available on their systems. My initial thoughts on attribute requirements are: USE attribute for "language of text" USE attribute for "geographic area" (instead of code-geographic-area) USE attribute for "location" (instead of code-institution) USE attribute for "microform-generation" USE attribute for "record-type" delete all the "code ..." USE attributes STRUCTURE attribute for "coded-info" a new attribute type for "language of term", values to be derived from ???? (note that many MARC records created by the National Library of Canada have subject headings in both French and English) a new, or modified, parameter for preferred language of text (and for preferred script of text?). Alternatively, it might be desirable to have this as a session constant which is negotiated at init time. Probably other work is required to support differences in romanization, etc. (What if I romanize Chinese according to Wade-Giles - "Peking", and the target romanizes with Pinyin - "Beijing"?). Anyway, using the above attributes, texts in English could be specified by using a search term "english" with use attribute "language-of-text" and structure attribute "word", or by using "eng" with use attribute "language-of-text" and structure attribute "coded-info". - />----------------------------------------------------------------<\ \ Joe Zeeman / / Software Kinetics Ltd \ | 65 Iber Road | \ Stittsville, Ontario voice: (613) 831-0888 / / Canada K2S 1E7 fax: (613) 831-1836 \ \>---------------------------------------------------------------- Sender: "Z39.50 Implementors Workshop" From: Wayne Davison Subject: ZIG agenda REPLY TO 09/03/91 09:50 FROM Z3950IW@NERVM.BITNET "Z39.50 Implementors Workshop": ZIG agenda Item 14. "Z39.50 PDUs directly over TCP" involves the possibility of developing a profile document and it therefore related in part to Item 2 "Profile documents". I suggest that these items be grouped together on the agenda. Since I will not be arriving until after the barbeque has started on Sunday, please scheduled these topics for Monday or Tuesday. - Wayne Davison To: Z3950IW@NERVM.BITNET cc: BL.MDS ======================================================================== Date: Tue, 3 Sep 1991 15:31:18 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Wayne Davison Subject: FINAL MEETING ANNOUNCEMENT REPLY TO 08/28/91 05:12 FROM Z3950IW@NERVM.BITNET "Z39.50 Implementors Workshop": FINAL MEETING ANNOUNCEMENT I am the fourth, probably, person from RLG, and I will be attending. I hope to arrive at the Barbeque before all the food and drink are gone. - Wayne Davison To: Z3950IW@NERVM.BITNET ======================================================================== Date: Tue, 3 Sep 1991 16:41:57 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Margery Tibbetts Sept. 3, 1991 Would someone please post to the list an updated copy of the Proximity Searching document and the Attribute set bib-1 document. I am looking for these documents with the changes from the Jan. 1991 and May 1991 ZIG meetings incorporated into the text. Thanks, Margery ======================================================================== Date: Tue, 3 Sep 1991 21:22:10 -0400 Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Greg Baber Subject: Re: FINAL MEETING ANNOUNCEMENT I will attend. Haven't heard about the barbecue, tho'. --gregb Reply to: Gregory S. Baber Tel: 609-520-5077 Dow Jones & Co., Inc. Fax: 609-520-4434 Box 300 UUCP: ..unet!warlock!gregb Princeton, NJ 08530-0300 ======================================================================== Date: Tue, 3 Sep 1991 20:53:18 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch Subject: more on coded attributes Following up on Joe Zeeman's latest posting, I would propose that we consider the following changes to bib-1: add structure attribute coded-info, with a specification of what coding it implies when used with a given use attribute such as language generalize the following use attribute for language becomes language of text use attribute for geographic code becomes geographis area use attribute for location instead of code-institution We should probably permit both coded-info and uncoded-info for these search attributes. This would permit a simple server to pass, for example, a language specification like "ENGLISH" to a server for resolution to a coded-info specification. additional attribute for language-of-term for search terms (much better in query than in init) i would also like to revisit character sets for query terms, which is starting to look like a serious screw-up in the existing standard. I am not entirely clear on the right approach for this, and think it would benefit from some discussion at the implementor's group meeting. Comments? Clifford ======================================================================== Date: Tue, 3 Sep 1991 22:06:29 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch Subject: record transfer questions Unresolved questions on record transfer syntaxes. For the upcoming meeting, I think we might want to revist two items of old business that Mark H. prepared in January 1991 Item 1 is what he titled "Element Set for Building Indexes" and which I would suggest is more accurately titled "Transfer syntax for summary bibliographic records"; this was, in essence, a simple transfer format for bibliographic records that is suitable for systems that don't want to cope with the MARC format. Do we want to register this? Do we want to look at extensions that would allow it to be used with abstracting and indexing databases? (and, Mark, are you planning to revise)? Item 2 is a document titled "Element set for OPAC use" which seems to me to be more accurately a "transfer syntax for opacs". This bundles a bibliographic data, multiple holdings information, and optional circulation status, at least as we discussed amending it at the meeting in Berkeley). Again, my questions are is this going to be revised into final form, and do we want to adopt this? Clifford ======================================================================== Date: Tue, 3 Sep 1991 22:28:57 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch Subject: diagnostic sets At the risk of raising a topic that nobody wants to hear about... In inspecting the most recent draft of Z39.50 I think that we need to devote some serious attention to the diagnostic message set. I think we are missing some necessary diagnostics, for example, for problems with proximity searching. In addition, what happens, for example, if we have a misformed type 1 query, that is, for instance, missing the relational attribute? I cannot see any obvious reason in the protocol that precludes a client from submitting an ill-formed query. As a related issue, I would like to question the assumption that a good diagnostic format consists simply of an error code and some supplementary text. I wonder if we don't need some supplementary structured fields to pass info back to the client --- for example, the maximum number of operators or terms supported, unsupported attributes that appear in a query, and the like, so that the client has a hope of deriving a specific error definition from a diagnositic. Tedious as it may be, I think that a solid set of diagnostic messages is critical if we are to have large-scale interoperability. I suggest that we discuss diagnostic record structures (appendix D) both in the context of whether the right data elements are present and in the context of whether the list in the draft Appendix D is comprehensive, at the meeting. Comments? Clifford ======================================================================== Date: Tue, 3 Sep 1991 22:42:34 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch Subject: v3: extra query info Following up yet another item from a previous Implementor's group meeting... This is a version 3 extension Add to the SEARCH APDU an indicatior that the client can set to flag that the client wants supplementary search information. Add to the SEARCH RESPONSE APDU a field that can contain supplementary search processing record as defined below 1. Term posting record this contains a term from the type 1 query followed by an integer which gives the number of records in the database on the server that match that term from the type 1 query. 2. Stopword record (note-- full lists of stopwords can be obtained by an EXPLAIN service; this will be covered by a later posting) this contains a term which is a stopword, and which thus has been ignored in subsequent search processing. Question: is this the right formulation? My notes indicate as addition possibilities (that get messy, and which I am inclined to omit) cardinality of partial query results, eg if the query is A and B and C (where A, B and C are terms) then if the server query procesor evaluated first A and b and then (A and B) and C that we would pass back to the client the cardinality of (A and B). In addition, my notes indicate some interest in tracking any query attributes that were generalized ("Fuzzied", to use Mark H.'s terminology) by the server and what they were generalized to. Comments? Clifford ======================================================================== Date: Tue, 3 Sep 1991 22:54:15 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch Subject: stateless servers Follow-up on stateless servers, multiple result sets and related matters. This is a version 3 change proposal. Discussions at previous implementor's group meetings have suggested requirements for the following functions: 1. permit the client to propose how many result sets it wants to maintain on the server, as a maximum, and have the server confirm this. 2. allow the client to determine if the server is running in a stateless mode, eg, does not maintain any result sets. Suggested method: 1. Add a field to the INIT APDU in which the client can specify the maximum number of result sets that it expects to maintain on the server at any one time. 2. Add a field to the INIT RESPONSE APDU (which must be less than or equal to the number of result sets requested by the client, if this optional field appeared in the INIT APDU) which specifies what the server will support, as follows: if value is 0 -- server is running stateless. Add-on searches are not permitted. if value is 1 -- server does not support result set naming; add-on searches are permitted, but only to modify the current result set. if value is greater than 1 -- server will make its best efforts to maintain N result sets, permit naming of these result sets in queries, and will try not to delete these result sets unilaterally. If the value is 0, we have some additional questions, such as whether non-piggyback presents are allowed. I would suggest that this be controlled though the specification of support of the PRESENT service element in the INIT, so that if the number of result sets is zero but PRESENTs are supported then a subseqent present is permissable. Question: does this meet the requirements? Anything else needed? Clifford ======================================================================== Date: Wed, 4 Sep 1991 09:25:32 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" In-Reply-To: Message of Tue, 3 Sep 1991 16:41:57 PST from OK, now I **THINK** I know what is going on in the THINK.COM ftp server. The ZIGs are in subdirectory /public/wais/z3950/ZIG. The index to them is in this subdirectory in the file ZIG.INDEX. The stuff in /public/wais/z3950 is the contents of the Z3950IW LISTSERV archives. I will be doing some work on them to make them more usable. I'll post to the list when completed. Margery, the updated proximity operation document is available via ftp at THINK.COM. Do: ftp think.com anonymous guest cd public/wais/z3950/ZIG get ZIG91-0015 I do not believe the most current bib-1 attr document is on the server but a previous version is in ZIG91-0009. ======================================================================== Date: Wed, 4 Sep 1991 09:33:30 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Re: record transfer questions In-Reply-To: Message of Tue, 3 Sep 1991 22:06:29 PST from I will revise both documents that Cliff mentions and bring them to the meeting. I would like to see some action taken on them as, if my memory proves accurate, the non-library folks were interested. ======================================================================== Date: Wed, 4 Sep 1991 06:47:28 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC Subject: bib-1 attributes (as requested) The changes in attributes from D3 to D4 (to be distributed at the meeting) affect only the Use attributes and Structure attributes. Below are listed only the affected Use attributes, and the complete set of Structure attributes. Author-title 1000 Record type 1001 Name 1002 Author 1003 Author-name personal 1004 Author-name corporation 1005 Author-name conference 1006 Identifier -- standard 1007 Subject -- LC children's 1008 Subject name -- personal 1009 Body of text 1010 Date/time added to database 1011 Date/time last modified 1012 Authority and format identifier 1013 Concept-text 1014 Concept-reference 1015 Structure: Phrase 1 word 2 key 3 year 4 date (normalized) 5 word list 6 date (un-normalized) 100 name (normalized) 101 name (un-normalized) 102 In addition, the following note is added to the relation table: "Note: "term" is the right operand of the relation. For example, if 'Use' is 'date', 'relation' is 'less than', and 'term' is '1800', then the relationship is "date less than 1800" " ======================================================================== Date: Wed, 4 Sep 1991 10:06:21 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ralph LeVan Subject: Re: v3: extra query info Sorry, but cardinality of partial results, while interesting, is often not possible on a smart server. For instance, the user said "GEOPOLITICS AND (ENGLISH OR UNITED STATES)". There will not be an intermediate result for "ENGLISH OR UNITED STATES" on my machine. Returning intermediate results implies a promise to the user that I'm going to do the search the way the user entered it. I reserve the right to reformulate their query. No intermediate results, please. Ralph Ralph LeVan Internet: rrl@rsch.oclc.org Online Computer Library Center UUCP: ...!saqqara!sppy00!rrl 6565 Frantz Rd, Dublin OH 43017 Phone: (614) 764-6115 ======================================================================== Date: Wed, 4 Sep 1991 09:58:57 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Peter Ryall Subject: Re: stateless servers In-Reply-To: Mail from 'Clifford Lynch ' dated Tue, 3 Sep 1991 22:54:15 PST Cliff, Is it possible that we could expand this field to indicate whether or not the 'N' result sets supported will be allowed to persist across associations, or do you feel this is overloading 'to the max' & it would be better to add a totally separate field for this purpose. In working on the persistent set capability, it is obvious we need some Init option to specifiy whether or not each Origin & Target will preserve sets across associations, & this needs to be independent of the proposed set management facility which may or may not be supported by a target which supports persistent result sets. I hope I have stated this clearly - otherwise, we can defer discussion until the meetings. The remainder of your proposal sounds good & should provide at least a stop-gap solution for stateless servers.. ======================================================================== Date: Wed, 4 Sep 1991 10:24:28 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ralph LeVan Subject: Directions to OCLC and Barbecue ASCII MAP TO OCLC I-270 ________________________________________________ / From Airport: North on \ / I-270, around beltway \ / to Rte 161 to Dublin. \ / 1st left is Frantz Rd and \ / OCLC OCLC. Frantz bends left \ / _______+ and becomes Post Rd with \ / Post Rdl Rte 161 Red Roof Inn and Mariott. \ _____+_________l________________ Turn right on Frantz and I I l right again to get to I I Staufersl Stauffers I I ______l Frantz Rd. I I / l I I-270 I l l I-670 I I ____________I I Airport I I I I I There is an Airport Shuttle that can take you from the airport to the hotels or OCLC. It costs $14.50 per person. Their number is 1-800-443-3519 to reserve a seat. They run every half hour from 8am to 11pm. Directions to barbecue, for those arriving late: Go past OCLC on Post Rd and turn right at stop sign (Coffman Rd). Turn left on Tara Hill ( < 1/2 mile). Turn left on Conquistador Ct ( ~1/2 mile). Barbecue at 6855 Conquistador Ct at end of street. Phone: 761-3128 Ralph Ralph LeVan Internet: rrl@rsch.oclc.org Online Computer Library Center UUCP: ...!saqqara!sppy00!rrl 6565 Frantz Rd, Dublin OH 43017 Phone: (614) 764-6115 ======================================================================== Date: Wed, 4 Sep 1991 08:08:40 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" Comments: Warning -- original Sender: tag was brewster@QUAKE.THINK.COM From: Brewster Kahle In-Reply-To: "Mark Hinnebusch, FCLA"'s message of Wed, 4 Sep 1991 09:25:32 EDT <9109041412.AA02980@Early-Bird.Think.COM> Date: Wed, 4 Sep 1991 09:25:32 EDT From: "Mark Hinnebusch, FCLA" OK, now I **THINK** I know what is going on in the THINK.COM ftp server. Sorry about the problems on think.com. We "cleaned" up our ftp directory and obviously screwed things up. It turns out that a cracker was using our directory as a place to put a bunch of cracking tools... The ZIGs are in subdirectory /public/wais/z3950/ZIG. The index to them is in this subdirectory in the file ZIG.INDEX. The stuff in /public/wais/z3950 is the contents of the Z3950IW LISTSERV archives. I will be doing some work on them to make them more usable. I'll post to the list when completed. Margery, the updated proximity operation document is available via ftp at THINK.COM. Do: ftp think.com anonymous guest cd public/wais/z3950/ZIG get ZIG91-0015 I do not believe the most current bib-1 attr document is on the server but a previous version is in ZIG91-0009. ======================================================================== Date: Wed, 4 Sep 1991 08:56:17 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch Comments on two postings from today: Peter Ryall's posting on persistent result sets. I did not address this because I don't think we have yet really converged on an approach to persistent results (I think this is on the meeting agenda for discussion). A part of a persistent result set function would clearly need to be some means of exchanging info about how many persistent results can be supported and how long they persist, but I think there are more basic modelling questions. My personal bias on persistent results (and I have not thought about this extensively) is that there should be a specific operation that the client invokes to convert a result set to a persistent object once it is created. I am much less clear about how client and server should exchange information about persistency capabilities and requirements. Good discussion topic for meeting. On Ralph's posting about cardinalities of intermediate results as supplementary info on a SEARCH RESPONSE APDU. I TOTALLY agree that the server must be free to do any type of query optimization it wants. My thought, however, was that many servers will compute at least some describable intermediate results when evaluating queries, and that they should have the option of describing those results and their cardinalitites if they wanted, as it is often useful info that can be presented to a user by a client to help him or her understand why a search produced the result it did. Bad idea? Clifford ======================================================================== Date: Wed, 4 Sep 1991 10:17:34 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Lennie Stovel Subject: character sets for query terms Clifford, Could you please review the reasons why characters sets for query terms (you're speaking of the OCTET STRING type, right) is starting to look like a serious screw-up? -- Lennie To: Z3950IW@NERVM ======================================================================== Date: Wed, 4 Sep 1991 14:01:29 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Franklin Davis In-Reply-To: Brewster Kahle's message of Wed, 4 Sep 1991 08:08:40 PDT <9109041618.AA06162@Early-Bird.Think.COM> Date: Wed, 4 Sep 1991 08:08:40 PDT From: Brewster Kahle Date: Wed, 4 Sep 1991 09:25:32 EDT From: "Mark Hinnebusch, FCLA" OK, now I **THINK** I know what is going on in the THINK.COM ftp server. Sorry about the problems on think.com. We "cleaned" up our ftp directory and obviously screwed things up. It turns out that a cracker was using our directory as a place to put a bunch of cracking tools... I hadn't heard this -- what's the story??! --F ======================================================================== Date: Wed, 4 Sep 1991 16:08:26 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Cynthia A. Vaughn" Subject: Mailing list for Z39.50 meetings/minutes If possible, please include me on the mailing list for the above. I am the Technical Standards Coordinator for OCLC and this info would be very helpful. Thanks. :) Sincerely, Cynthia A. Pabisinski Technical Standards Coordinator OCLC, Inc. ======================================================================== Date: Wed, 4 Sep 1991 16:55:27 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Re: Mailing list for Z39.50 meetings/minutes In-Reply-To: Message of Wed, 4 Sep 1991 16:08:26 EDT from I have added you. Welcome. ======================================================================== Date: Wed, 4 Sep 1991 15:12:14 -0700 Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark H. Needleman" Subject: agenda item Clifford suggested I put an item on the agenda to fill folks in on the IETF network fax working group I chair and the work we have been doing to define a common image transmission format for fax and to discuss wether we want to register this as a transfer syntax in z39.50. Also to people's thoughts on wether we should ASN.1'ize the image transfer format. Ill bring a copy of the draft image format document to the meeting Mark Needleman ======================================================================== Date: Wed, 4 Sep 1991 13:51:46 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch Subject: explain draft Here, finally, is a first draft of the details of the EXPLAIN service. It is not a polished specification, but rather a draft of a specification that includes discussions of some of the design decisions and open design issues. I hope that it will provide a good, concrete basis for discussion at the implementor's group meeting and over the mailing list, however. I have borrowed shamelessly from major work done by Wengyik, Brewster and Liv Holm, as well as many suggestions from others. Comments welcome. Please note that I have not actually generated any ASN.1, for two reasons -- I find prose easier to follow at stage of a specification, and because I would be much happier if somebody more fluent than I in ASN.1 would take care of that part of the job once we settle on the details. Clifford Towards an EXPLAIN facility for Z39.50. Draft of 9/4/91. Introduction There is a need for clients to determine information about databases available on a Z39.50 server, the contents of these databases, the access points and search types that are supported for each database, and other assorted information about the server (such as who to contact for further information). The emphasis here is on defining information structures that will facilitate effective communcation between clients and servers without the need for prior "outside-of-protocol" agreements. This document proceeds in several steps. The first section defines queries that a client can submit to the server and the data elements that the server may return to the client in response to such queries. The second part of the document discusses the mechanics of query submission and response. Note that this is intended to be an extensible facility, in the sense that: (1) additional data elements can be added to query responses defined here (2) additional queries and responses can be defined. In addition, I would assume that virtually every response data element listed below is optional. I have attempted to carefully differentiate information that is only suitable for display to a human user of a client from more structured information that might be processed by client software directly. I have used the term human-readable for the former category of data. There is provision for human-readable material to be fetched from the server in multiple languages; however, I have skirted character set issues since I don't understand their relationship to things like presentation very well. This multi-lingual support is handled by asking for a specific language in the query; in the response, the human-readable fields are either in that language or are replaced by placeholders that indicate that the field is not available in the requested language, and listing the language(s) in which the field is available. A related area that causes significant trouble is the formatting to be done in the human-readable fields. This could be simple ASCII, SGML (in which case, where does the DTD go, for instance?), or PostScript. I have not dealt with this issue yet, and would appreciate comments. I note we do not even have an agreement on how to delineate line breaks and paragraph breaks in ASCII. Queries and Response Data Elements Server-Level Queries Query: General information about server parameters: language Response: name of server list of server nicknames preferred server nickname (may be selected by server as a function of language requested by client) description of server (human-readable) useage restrictions on server (human-readable) "eg use of this server is supposed to be limited to the faculty, students and staff of the Univesity of..." name/address of contact people for server (human-readable) e-mail address to communicate with server management.(ASCII string) news message about this server (human readable) recent informative message about this server that server might like client to display to the end user. should be accompanied by posting date of news message and expiration date (optional) of news message. example: this server will be down for special maintinence work tomorrow, may 3, all day. icon that the client might use to represent the server (there is a format issue here; perhaps embed an object using the image transfer format? or just a small bitmap) Query: List of Available Databases parameters: language Response: list of database entries, each one of which contains a database name and (optionally) a brief human-readable description of the contents of the database. optionally, an icon that the client could use to represent each database in a graphical user interface. Query: Info about server's Z39.50 functionality parameters: none Response flag: server does/does not support result set naming flag: server does/does not support multiple DB searching Database-level queries Query: General information about a database parameters: language, database-name response: human-readable description of contents of database database nicknames(aliases) preferred database nickname (may be set by server based on client language preference) actual number of records in database estimated number of records in database, and date of estimate average record length maximum record length date of last update frequency of update cost information (we need to discuss the way this should be encoded) copyright statements (this should be at least human-readable, and perhaps should have at least a summary machine-processable indicator for public-domain vs copyrighted/restricted distribution.) database producer name/address (human readable) disclaimers (human readable) news message about this database (human readable) recent informative message about this database that server might like client to display to the end user. should be accompanied by posting date of news message and expiration date (optional) of news message. icon that the client might use to represent the database (there is a format issue here; perhaps embed an object using the image transfer format? or just a small bitmap) structured data object(s) describing the contents of this database --- this is related to work going on in the CNI directories working group and this info will be described elsewhere, but we need a placeholder for now. There have been numerous other proposals for things that go in here. I'll mention a few: languages of database, type of database (bibliographic, full text, etc), chronological coverage of database.... I have avoided these at the moment because they either beg complex taxonomic or registry issues; some might be factored into the CNI thing above. Of course, these can all easily be put into the human-readable database description if the server wishes. The issue I have skirted is defining them so a client program can understand them. query: general z39.50-related information about a database parameters: language, database-name response: default element set name list of other element set names supported, each optionally accompanied by a brief human readable description in addition, a partial ordering defining which element set names are subsets of which other element set names. I am open to suggestions on an elegant way to represent this partial ordering among the element set names. list of transfer syntaxes supported (I have some questions about how to represent these that I want to discuss at the meeting) list of diagnostic sets supported (ditto) list of resource control report formats supported (ditto) list of attribute sets supported (ditto) query: attribute-specific z39.50--related information about a database. parameters: language, database-name, attribute-set-name (Note: I believe this works for bib-1; we will have to evaluate whether it generalizes to other attribute sets as new ones get defined) response: a list of each use attribute in the attribute set that is supported by the server; for each of these useage attributes a list of the combinations of postion/relation/structure/truncation/completeness attributes that are supported. optional: a human readable field explaining interpetation of the useage attribute and how it is searched. (There are some specifics of encoding this info that we should discuss at the meeting) optional: a list of use attributes (perhaps qualified by other attributes) that are NOT supported by this database, a suggested alternative that IS supported by the database, an indicator saying: (1) result is a proper subset of unsupported indicator (example, DB supports personal author but not author) (2) result is a superset of unsupported attribute (example, DB supports author but not personal author), or (3) result has some overlap but that's all (eg DB supports Title but not subject searching). Additionally: a level of quality indicator, and space for human-readable comments (In essence, this is the redirection/fuzzying information that we have discussed at some of the ZIG meetings) Transfer Mechanism Considerations In initially thinking about this function, I modelled it as a distinguished database with a "well-known" name on the server which the client could search just like any other database. After carefully enumerating the queries and their parameters, the justifiction for formulating EXPLAIN operations as database queries seems weak to me. I am wondering if an additional APDU set EXPLAIN-REQUEST and EXPLAIN-RESPONSE might be a simpler way to deal with this, since it avoids registering transfer syntax for all of the reponses and simply puts them directly into the protocol. I would like to revisit this issue at the meeting. A final note: I suspect that some of these responses can be rather large -- perhaps larger than a maximum APDU. We will probably have to build in mechanisms to deal with this. If we model it as a database, we have already got a proposed mechanism on the table, at least. The database model that I would propose, if we go that route, would include the following access points: database-name explaination-type (corresponds to query type above) attribute-set name language (for human readable info) format (for human readable info) these would be the things that would have to go into an attribute set explain-1 as use attributes, if we wanted to do that. Another alternative would be to just "overload" them into bib-1 to avoid forcing clients and servers to deal with multiple attribute sets at this stage of protocol development. And, of course, we'd need transfer syntax for the response data elements that I described above. Another advantage to setting it up as a database is that it would be possible for a client to do searches that pull a lot of information in a single interchange, such as retrieving all records of type database-description (without supplying a database name) if APDU sizes permit. ======================================================================== Date: Thu, 5 Sep 1991 09:09:04 AST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Glenn Davidson Subject: Re: FINAL MEETING ANNOUNCEMENT > This is the OFFICIAL call for attendance for the next Z3950 ZIG, > to be held at OCLC, in Dublin, Ohio, USA, starting at noon on Sunday, > September 8, 1991 and terminating at 3 pm on Tuesday, September 10. If > you plan on attending, please respond to this list so that Ralph can > get a seat count. Also, if you wish to take Ralph up on his gracious > offer of a Sunday barbeque please so indicate. > > This is also the first call for agenda items. > > -mark I am glad to inform you that I have received final approval to attend the Z3950 ZIG in Dublin Ohio to represent Acadia University. I also will arrive in time to attend the B.B.Q. on Sunday. I apologize for the short notice. ***************************************************************************** Glenn E. Davidson, User Consultant, Computer Centre Address: Acadia University, Wolfville N.S. B0P 1X0 Phone: (902) 542-2201 Ext. 438, Email: GLENN@ACE.ACADIAU.CA ***************************************************************************** ======================================================================== Date: Thu, 5 Sep 1991 10:54:58 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Joe Zeeman Subject: Re: FINAL MEETING ANNOUNCEMENT In-Reply-To: ; from "Glenn Davidson" at Sep 5, 91 9:09 am > I am glad to inform you that I have received final approval to > attend the Z3950 ZIG in Dublin Ohio to represent Acadia University. I > also will arrive in time to attend the B.B.Q. on Sunday. I apologize > for the short notice. > > > ***************************************************************************** > Glenn E. Davidson, User Consultant, Computer Centre > Address: Acadia University, Wolfville N.S. B0P 1X0 > Phone: (902) 542-2201 Ext. 438, Email: GLENN@ACE.ACADIAU.CA > ***************************************************************************** > WATCH OUT!!!! We're taking over ... -- />----------------------------------------------------------------<\ \ Joe Zeeman / / Software Kinetics Ltd \ | 65 Iber Road | \ Stittsville, Ontario voice: (613) 831-0888 / / Canada K2S 1E7 fax: (613) 831-1836 \ \>---------------------------------------------------------------- Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Re: FINAL MEETING ANNOUNCEMENT In-Reply-To: Message of Thu, 5 Sep 1991 10:54:58 EDT from Does this mean I have to put an "eh?" on the end of every agenda item? ======================================================================== Date: Thu, 5 Sep 1991 11:29:16 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Final Agenda Final Agenda Z39.50 Implementors' Group Meeting September 8-10, 1991 OCLC, Dublin, Ohio A. Standard and Profile Administration 1. Draft 4 of Z39.50 version 2 (Denenberg) 2. Z39.50 Enhancements tracking mechanism (Denenberg) 3. Maintenance Agency registration of implementors (Denenberg) 4. Relationship of ZIG to NIST OSI Workshop (Denenberg) 5. Profile documents: (Denenberg) SR PICS Proforma Z39.50 PICS Proforma ZIG PRL (Profile PICS Requirements List) 6. Identifying implementation types (Kunze) 7. Z39.50 PDUs directly over TCP (Stovel) 8. Profile restrictions of data element lengths (Sullivan) 9. Test bed (Greenfield) B. Currently supported service 10. TC46 work on Explain and Browse (Zeeman) 11. Explain (Randall,Lynch) 12. Review of Resource Report Format bib-1 replacement (Lynch) 13. Review of Diagnostic message set (Lynch) 14. Proximity vis-a-vis Result Set Models (Lynch) 15. Review of Proximity Operators in ASN.1 (Hinnebusch) 16. code-language vs. content-language USE attribute (Lynch,Zeeman) C. Proposed services 17. Persistent result sets (Ryall) 18. Periodic search service (Ryall) 19. Financial/news attribute set (Ryall) 20. Local Record Syntaxes (Lynch) 21. Brief and expanded bibliographic abstract syntaxes (Hinnebusch) 22. NETFAX transfer syntax (Needleman) 23. Browse (Randall) 24. Segmentation facility (Lynch) 25. Abort current operation (Lynch) 26. Resource report request (Lynch) 27. Supplementary search information (Lynch) 28. Stateless servers (Lynch) ======================================================================== Date: Thu, 5 Sep 1991 12:19:01 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Cynthia A. Vaughn" Subject: Re: Mailing list for Z39.50 meetings/minutes Thank you! :). ======================================================================== Date: Thu, 5 Sep 1991 13:21:26 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch Subject: z3950 over TCP/IP One of my writing assignments from previous ZIGs was to draft up a document describing how to layer Z39.50 on top of TCP -- my personal theory is that this is going to be one of the biggest interoperation problems as we move ahead. Here's a draft document to guide our discussion, prepared with much help from Mark Needleman and Michael Thwaites at DLA. Comments? I am not particularly happy with this document, but I view it as a key one. Perhaps some of the folks who are really up on their presentation layers and ASN.1 can jump in and help clarify further. --> Maximum number of output lines reached, remaining command output flushed.