======================================================================== 22 Date: Wed, 30 Jan 91 11:03:49 EST From: "Mark Hinnebusch, FCLA" Subject: Final agenda To: "Z39.50 Discussion List" The following is the final agenda. See you at the meeting. 1. Restatement of purpose and introductions (Hinnebusch) 2. Status Reports 3. Z39.50 Version 2 Draft 2 (Denenberg) 4 Reaffirmation of application profile (Denenberg) 5. Maintenance agency registration of implementors (Denenberg) 6. OSI IP over the Internet (Denenberg) 7. Z39.50 over TCP/IP (Yeong) 8. Z39.50 vs. ISO 10162/63 with update (Michael) 9. Type 2 Queries (LeVan) 10. Element sets for indexes (Hinnebusch) 11. Updated/additional bib attribute set (Hinnebusch) 12. Element sets for OPACs (Hinnebusch) 13. Proximity searching (Hinnebusch) 14. TESLA program at ALA in Atlanta (Hinnebusch) ======================================================================== 21 Received: by NERVM (Mailer R2.07) id 1140; Wed, 30 Jan 91 09:30:25 EST Date: Wed, 30 Jan 91 06:33:32 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC X-To: z3950iw@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" Mark - please put items 12 and 13 early in the agenda (Z39.50 Version 2 Draft 2 and Reaffirmation of application profile). For item 12, I would like to distribute the document early in the meeting, speak briefly about it, let everyone have the evening to look at it, and have further discussion if necessary on Friday. On the other hand, items 3 and 4 may be moved to the end of the agenda. I don't recall an action item on recursion. --Ray ======================================================================== 72 Resent-Date: Wed, 30 Jan 91 08:22:01 EST Resent-From: "Mark Hinnebusch, FCLA" Resent-To: Rich Received: from RLG.BITNET by NERVM.NERDC.UFL.EDU (Mailer R2.07) with BSMTP id 9354; Wed, 30 Jan 91 00:33:13 EST Date: Tue, 29 Jan 91 12:12:19 PST To: FCLMTH@NERVM.BITNET From: "Rich Fuchs" Subject: OSICS session dispatching >We're currently considering how OSICS fits into our current >environment - MVS with some locally confected stuff that serves >as our TP monitor & none of your standard IBM TP facilities above >MVS. You must have VTAM to use OSI/CS. You can get to OSI/CS from another MVS address space either via cross-system services SVC or via APPC. >From the OSICS documentation, it appears that applications are >meant to be single-threaded.... at least this is what I assume >from the fact that, once you've done OSLISN in a given >environment (as set up by OSAEE & friends) you don't get to do >another OSLISN. But from your ZIG comment > > > Date: Thu, 3 Jan 91 09:03:23 EST ... > > > > Speaking only for the IBM OSI/CS environment, you issue a LISTEN. When an > > a-associate comes in, you are given, by the OSI/CS, a unique association > > ID which you then use as a handle for the association. In this environment > > you would index your state tables with the associationID to ascertain the > > current state of the association. ... >it appears that you're handling multiple sessions with a ad-hoc >monitor. You can only have one OSLISN active at one time but you can issue the OSLISN asynchronously and use OSCHKA to look for a response. Using this with a timeout should allow you to round-robin through all active associations. Or at least I hope so because that is what I plan to do. >Two questions: > 1) Can you have multiple OSICS environments in a single > address-space? no, you can not. However, you can have multiple OSICS environments in multiple address spaces, each with its own unique identifier. > 2) We'd rather use operating system facilities for dispatching > these sessions if possible, like so: > init_new_environment > listen > fork.... > > But we're stuck with raw MVS - no fork - & C370 doesn't seem > to have the hooks to use facilities like MVSATTACH. How have > you handled session management with OSICS? I am going to convert the APDU to an APPC message which I will ship off to the CICS that my NOTIS system runs under. Then I forget it. The NOTIS system, at some later time, sends me a response APPC message. I turn that into a response APDU and ship it out the OSI door. Of course, the Z39.50 support software will keep control blocks for each association to verify valid activities. This is all still a little hazy to me. I have been worrying more about the APPC side of things recently and some of my thinking about the OSI/CS doesn't come right back easily. Old age, I guess. As soon as I get it all down conceptually, I will be documenting it and making the document available in the public domain. I'll advertise that on Z3950IW. ======================================================================== 26 Date: Wed, 30 Jan 91 08:09:32 EST From: "Mark Hinnebusch, FCLA" To: "Z39.50 Implementors Workshop" In-Reply-To: Message of Tue, 29 Jan 91 10:29:55 PST from Larry: - new element set for indexes At the last meeting, I was assigned (offered?) to produce a draft set of elements to be returned for the express purpose of building an index. This was to releive the traffic of sending full records just to build an index. - change to attribute set bib-1 or new attrbute set bib-2 I alluded to this item at the last meeting. As we began to do detailed design we discovered that the current attribute set IN OUR OPINION is not sufficient for use in public catalog systems. I have some suggestions. Should be a lively discussion :-) - element sets for OPAC use In a public catalog environment, the bibliographic data is not the end product of a search. Rather, holdings data and circulation data is (for the moment ignoring the idea of sending the entire document). This is a first shot at an ASN.1 description of a union of this data. ======================================================================== 47 Date: Tue, 29 Jan 91 14:52:21 EST From: "Mark Hinnebusch, FCLA" Subject: Preliminary Agenda To: "Z39.50 Discussion List" The following is the preliminary agenda. I am open to reordering. 1. Restatement of purpose and introductions (Hinnebusch) 2. Status Reports 3. Maintenance agency registration of implementors (Denenberg) 4. OSI IP over the Internet (Denenberg) 5. Z39.50 over TCP/IP (Yeong) 6. Z39.50 vs. ISO 10162/63 with update (Michael) 7. Type 2 Queries (LeVan) 8. Element sets for indexes (Hinnebusch) 9. Updated/additional bib attribute set (Hinnebusch) 10. Element sets for OPACs (Hinnebusch) 11. Proximity searching (Hinnebusch) 12. Z39.50 Version 2 Draft 2 (Denenberg) 13. Reaffirmation of application profile (Denenberg) 14. TESLA program at ALA in Atlanta (Hinnebusch) Outstanding action items (at least according to my notes) include: A. EXPLAIN service (Lynch and Yeong) B. Non-recursive alternative to RPNQuery (Denenberg) C. Attribute sets and element sets for full-text retrieval (Davis) D. Transfer syntax for full-text (Davis) E. Z39.2-based non-bibliographic data attribute and element sets (Michael?) F. Sorting and Ranking results sets at the target (Kibbey) G. Dynamic delivery of ASN.1 descriptions of database records (?) H. Batching search requests (Zeeman) I. Adding user information fields to all APDUs (?) J. Stoplists (Lynch and LeVan) K. Resource Control (Lynch) L. Error Message Sets (LeVan) M. Priority of services (Hinnebusch) N. Browse (Kibbey and LeVan) O. Search cancellation (Lynch) P. Informatory messages on any command (?) Q. Defining adhoc views and element set subsets (?) Any interest in adding any of these to the agenda? Post desired changes to the list. I will update this mailing and repost at 11AM tommorrow morning, (Eastern time), then drive to Jacksonville to catch my plane. If there are any administrivia to be dealt with before that, let me know ASAP. Otherwise, see you'all in California! ======================================================================== 15 Received: by NERVM (Mailer R2.07) id 6992; Tue, 29 Jan 91 14:45:09 EST Date: Tue, 29 Jan 91 11:23:53 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC X-To: z3950iw@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" Mark- Please add the following three items to the agenda: - Maintenance agency registration of implementors - OSI IP over the Internet - Affirmation of application profile The first two will be brief. The third might require some involved discussion. --Ray ======================================================================== 31 Received: by NERVM (Mailer R2.07) id 7778; Tue, 29 Jan 91 19:10:03 EST Date: Tue, 29 Jan 91 10:29:55 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Sally McCallum - LC To: "MARK HINNEBUSCH, FCLA" TO: Mark Hinnebusch (and other interested parties) FROM: Larry Dixson, LC SUBJECT: Re: meeting agenda Yesterday, you listed several agenda topics. Several of those topics were a bit too briefly stated for me. Could you, in a few sentences, let me have a little more background? Thanks very much. -- new element set for indexes for OPACs ??? Is this related to browse result sets? -- amended attribute set bib-1, or alternately, a new set, bib-2 What are some of the attributes involved? -- element set for OPACs, a superset of MARC bib data ??? -- change to ASN.1 to support proximity searching I remember this mail on the list. No explanation is necessary. ======================================================================== 18 Date: Tue, 29 Jan 91 12:42:38 EST From: "Mark Hinnebusch, FCLA" Subject: Re: IBM OSI/CS To: "Z39.50 Implementors Workshop" In-Reply-To: Message of Mon, 28 Jan 91 14:52:36 PST from In reply to jay Fields' question on OSI/CS. We (FCLA) have installed the mainframe version and loopback tested it. We are interested in doing a real test with some other OSI shop ASAP. The product looks real good. It seems to have a great deal of flexibility. It supports X.25 and also ISO CNLP. The bottom three layers are implemented in VTAM and NPSI on the 37xx FEPs. To the best of my knowledge, through the 37xx is the only way out the door. I hear rumors that the 8132? will be an alternate door to use when the Internet goes dual-stack but I don't have any hard info on that. -- mark hinnebusch ======================================================================== 21 Received: by NERVM (Mailer R2.07) id 4895; Tue, 29 Jan 91 09:06:19 EST Date: Tue, 29 Jan 91 09:07:02 EST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ralph LeVan Subject: Type-2 Queries X-To: z3950iw@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" I've been asked to point to a reference to type-2 queries. In the draft of z39.50, version 2, that was distributed at the last meeting, zig90-010, page asn1-5, in the definition of Query, in the definition of SearchRequest: type-2 [2] EXTERNAL. Hey, it references the ISO8777 standard, instead of the NISO z39.58 standard. Well, don't I look foolish. Too bad. Of the 2, the NISO standard was better. I guess I still want a chance to talk briefly about the problems we have with ISO8777. Ralph ======================================================================== 22 Received: by NERVM (Mailer R2.07) id 2977; Mon, 28 Jan 91 17:52:59 EST Date: Mon, 28 Jan 91 14:52:36 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Jay Field Subject: IBM OSI/CS To: "MARK HINNEBUSCH, FCLA" RLG is planning on getting the IBM OSI/CS product for both the mainframe and the PS/2 (under OS/2). I would really appreciate any feedback from any of the group who are currently using the mainframe product. (The OS/2 version is announced but not yet shipped as far as I know.) I am also new to the group and looking forward to the meeting this week and getting to know people also working on Z39.50 implementations. Jay Field BR.JWF@RLG.BITNET To: Z3950IW@NERVM.BITNET ======================================================================== 14 Received: by NERVM (Mailer R2.07) id 2901; Mon, 28 Jan 91 17:41:44 EST Date: Mon, 28 Jan 91 16:39:46 CST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: JIM MICHAEL-DATA RESEARCH Subject: MTG. AGENDA To: "MARK HINNEBUSCH, FCLA" I would to add to the following to the agenda: A short discussion (if that is possible with this group) of the relationship of Z39.50 to the ISO Search and Retrieval protocol including the status of the Update function of the ISO S&R. Jim Michael JIM@DRANET.DRA.COM ======================================================================== 22 Received: by NERVM (Mailer R2.07) id 1589; Mon, 28 Jan 91 13:58:41 EST Date: Mon, 28 Jan 91 13:57:23 EST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ralph LeVan Subject: Re: meeting agenda X-To: Z3950IW%NERVM.BITNET@cunyvm.cuny.edu To: "MARK HINNEBUSCH, FCLA" I'd like to talk about type 2 queries. The type 2 queries are different between the ISO and ANSI and pose a potentially big barrier to interoperability, since they represent the human-enterable form of query. Besides being different, they are ambiguous grammers and are generally distasteful. If anyone knows what we can do to correct/amend them, please bring that information with them. 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 ======================================================================== 11 Received: by NERVM (Mailer R2.07) id 0559; Mon, 28 Jan 91 11:04:53 EST Date: Mon, 28 Jan 91 08:07:43 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC X-To: z3950iw@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" Mark - please add "Z39.50 version 2 draft 2" to the agenda. The document will be distributed at the meeting. I will have additional items tomorrow. --Ray ======================================================================== 22 Received: from NERVM by NERVM.NERDC.UFL.EDU (Mailer R2.07) with BSMTP id 0208; Mon, 28 Jan 91 10:25:36 EST Received: from spartacus.psi.com by nervm.nerdc.ufl.edu (IBM VM SMTP R1.2.2MX) with TCP; Mon, 28 Jan 91 10:25:34 EST Received: from localhost by spartacus.psi.com (5.61/1.3-Performance Systems International) id AA00330; Mon, 28 Jan 91 10:22:18 -0500 Message-Id: <9101281522.AA00330@spartacus.psi.com> To: fclmth@nervm.nerdc.ufl.edu Subject: Z39.50/TCP agenda item Reply-To: yeongw@psi.com Date: Mon, 28 Jan 91 10:22:16 -0500 From: yeongw@spartacus.psi.com I don't know if you're accepting agenda items for the upcoming Oakland meeting, but I'd like to discuss Z39.50 over TCP at the meeting, so could that please be added to the agenda? Thanks. Wengyik ======================================================================== 19 Date: Mon, 28 Jan 91 10:02:04 EST From: "Mark Hinnebusch, FCLA" Subject: meeting agenda To: "Z39.50 Discussion List" It is time to set the agenda for the next meeting. Please post your items to the list, Z3950IW@NERVM or Z3950IW@NERVM.NERDC.UFL.EDU, not to me personally. I have the following items: - new element set for indexes for OPACs - amended attribute set bib-1, or alternately, a new set, bib-2 - element set for OPACs, a superset of MARC bib data - change to ASN.1 to support proximity searching I will bring documents on these. The items that would change Version 2 can, if necessary, be delayed for version 3 but I would like to get consensus on them now. ======================================================================== 34 Received: by NERVM (Mailer R2.07) id 9163; Fri, 25 Jan 91 19:03:51 EST Date: Fri, 25 Jan 91 16:05:06 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC To: "MARK HINNEBUSCH, FCLA" To: Markku Savela cc. Z3950iw@nervm.bitnet > My "IMPLICIT SEQUENCE" comment concerned the following lines: > > ListStatuses ::= IMPLICIT SEQUENCE OF SEQUENCE{ ... > AttributeElement ::= IMPLICIT SEQUENCE ... > Both are referenced from other sequences with "... [tag] IMPLICIT ..." > so, they should be defined as (above lines don't pass ASN.1 syntax): > > ListStatuses ::= SEQUENCE OF SEQUENCE{ ... > AttributeElement ::= SEQUENCE ... You're right. Thanks. > ..... maybe this is required to produce some very specific > predefined octet stream? Yes. Specifically, it must be bit compatible with ISO SR (ISO 10162/10163). > Could Ray Denenberg give some other mail address. Looks like >"BB.RAY@RLG.BITNET" doesn't work for me, and maybe I shouldn't post >these details to the whole list. My actual address is bb.ray@rlg.stanford.edu. However, messages like these should indeed be posted to the list.  ======================================================================== 61 Received: by NERVM (Mailer R2.07) id 7129; Fri, 25 Jan 91 12:41:48 EST Date: Fri, 25 Jan 91 19:38:46 +0200 Reply-To: Markku Savela Sender: "Z39.50 Implementors Workshop" From: Markku Savela To: "MARK HINNEBUSCH, FCLA" In-Reply-To: Ray Denenberg - LC's message of Fri, 25 Jan 91 06:31:07 PST <9101251500.AA21472@tel3.tel.vtt.fi> >From: Ray Denenberg - LC >Additional notes: You missed two errors caused by mistyped case of an identifier (ASN.1 is case sensitive--at least my compiler thinks so). - one occurrence 'DataBaseName' -> 'DatabaseName', and - one occurrence 'ResultSetID' -> 'ResultSetId'. > - I don't think that "IMPLICIT SEQUENCE OF SEQUENCE{" is incorrect, > however, I need to check this out. Anyone know for sure? My "IMPLICIT SEQUENCE" comment concerned the following lines: ListStatuses ::= IMPLICIT SEQUENCE OF SEQUENCE{ ... AttributeElement ::= IMPLICIT SEQUENCE ... Both are referenced from other sequences with "... [tag] IMPLICIT ..." so, they should be defined as (above lines don't pass ASN.1 syntax): ListStatuses ::= SEQUENCE OF SEQUENCE{ ... AttributeElement ::= SEQUENCE ... Now that I have sort of got involved, I am slightly curious about definition style. I see following constructions: 1) SEQUENCE { .... .... [x] IMPLICIT A -- with a tag .... } 2) SEQUENCE { .... A -- e.g. without a tag } and then A is defined A ::= [y] IMPLICIT ... where x <> y. In case 1) content of A gets tagged with [x] ([y] is ignored I think) and in case 2) the tag will be [y]. But, as I know practically nothing about Z39.50, maybe this is required to produce some very specific predefined octet stream? regards, -- Markku Savela (savela@tel.vtt.fi), Technical Research Centre of Finland Telecommunications Laboratory, Otakaari 7 B, SF-02150 ESPOO, Finland ps. Could Ray Denenberg give some other mail address. Looks like "BB.RAY@RLG.BITNET" doesn't work for me, and maybe I shouldn't post these details to the whole list. ======================================================================== 69 Received: by NERVM (Mailer R2.07) id 6695; Fri, 25 Jan 91 11:21:19 EST Date: Fri, 25 Jan 91 08:14:00 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC Subject: delete changes To: "MARK HINNEBUSCH, FCLA" I want to address Wengyik's concerns about the changes to the delete. First, some background. During development of Z39.50 within NISO, the major requirement (relevant to this discussion) expressed with respect to "delete" was: a target MUST echo the name of a result set which was explicitly requested to be deleted, as well as to give the status of the operation; however, the target would not list those result sets deleted which were not explicitly requested to be deleted (i.e. on a bulk delete) but simply (try to) tell which ones it failed to delete. The key players who articulated this requirement were OCLC and DLA (i.e. Clifford Lynch). The U.S. delegation to TC46 worked hard to get the NISO delete incorporated into SR, which is now a DIS. However, during DIS ballot, OCLC expressed a requirement to generalize the "single" operation to "list". This is a serious requirement for OCLC, or they would not have proposed it at this late stage of SR progression and therefore the U.S. is obligated to argue for this change. However, the change should (1) have as little impact as possible on the delete service, and (2) preserve the original requirement expressed above. I should also note, emphatically (and apologize for not having already made this clear) that this (tentative) change was made to Z39.50 for compatibility with SR, and that if the U.S. is unsuccessful in arguing for this change at the upcoming TC46 editing meeting, then it will be backed out of Z39.50. I must further emphasize that the U.S. has already submitted comments and the ballot has closed. As difficult as it will be to argue for those changes at this stage of balloting, it will be even more difficult if we introduce additional changes which were not on the ballot comments (although some will have to be introduced, because the comments were drawn up hastily and they have some errors). Now to address the specific concerns: Since the "list" operation could be viewed functionally as very similar to doing several individual "single" operations, it follows (given the original U.S. requirement) that the result-set-ids must all be echoed on the response, and individual statuses given for each. Therefore, if the operation is "list" then liststatuses must contain every result set which was on the list. But if the operation was "all" it should contain entries only for those result sets not deleted. This requirement can only be specified by comment. I can see now that the comment in the draft does not do the job. In particular, the comment under bulkstatuses should say "individual statuses limited to failure-3 through failure-6" instead of "... success through failure-6". Even beyond that the comments can certainly be further improved. I'll fix it. But it is not true that listStatuses and bulkStatuses are semantically identical, because listStatuses reports status for result sets which were deleted as well as those not deleted, and bulkStatuses reports status only for those not deleted. The generalization from "single" to "list" does introduce a distinction between the status of the operation and the statuses for individual result sets on the list. Some of these status values overlap. For instance, the target may wish to report that it could not perform the operation at all, due to access control failure (in which case, perhaps the parameter listStatuses should not occur). On the other hand, it might have been unable to delete a specific result set because of access control failure.  ======================================================================== 45 Received: by NERVM (Mailer R2.07) id 5883; Fri, 25 Jan 91 09:29:51 EST Date: Fri, 25 Jan 91 06:31:07 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC To: "MARK HINNEBUSCH, FCLA" My thanks to Markku Savela for reporting the syntax errors in the ASN.1. These corrections are very timely, since I have not yet finalized draft 2. Based on this, I have applied the following corrections to the draft: _______________________________________________________________ Replace the trailing bracket with comma: ! deleteResultSetResponse [27] IMPLICIT DeleteResultSetResponse} Identifier should be lower case in the following lines: ! IdAuthentication [7] ANY OPTIONAL, ! Result [12] IMPLICIT BOOLEAN, ! ResultSetName [17] IMPLICIT VisibleString, ! SuspendedFlag [39] IMPLICIT BOOLEAN, -- "true" = ! ContinueFlag [42] IMPLICIT BOOLEAN, -- "true" = ! ResultSetWanted [43] IMPLICIT BOOLEAN OPTIONAL} ! {EstimateType [1] IMPLICIT INTEGER -- from table, determined ! EstimateValue [2] IMPLICIT INTEGER -- the actual estimate} Add comma at end of following lines: ! resultSetStatus [26] IMPLICIT PartialResults OPTIONAL ! bulkStatuses [35] IMPLICIT ListStatuses ! notAllRsltSetsDeletedOnBulkDlte (8) Replace trailing comma with right bracket: ! addinfo VisibleString, -- add'l information. Change "{SEQUENCE" to "SEQUENCE{": ! DeleteResultSetResponse ::={SEQUENCE _____________________________________________________________________ Additional notes: - All reported errors pertaining to hyphenation within comments are a result of formatting the document for electronic mail distribution. - I think that all other reported errors are compiler-specific. I would appreciate any efforts from other ZIG members to similarly analyze this report to see if I've missed anything. - I don't think that "IMPLICIT SEQUENCE OF SEQUENCE{" is incorrect, however, I need to check this out. Anyone know for sure? My thanks again to Markku Savela. ======================================================================== 124 Received: by NERVM (Mailer R2.07) id 5536; Fri, 25 Jan 91 08:16:08 EST Date: Fri, 25 Jan 91 08:12:27 -0500 Reply-To: z3950iw@nervm.nerdc.ufl.edu Sender: "Z39.50 Implementors Workshop" From: yeongw@SPARTACUS.PSI.COM Subject: Re: Z39.50 ASN.1 X-To: z3950iw@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" In-Reply-To: Your message of Thu, 24 Jan 91 06:22:35 -0800. <9101250016.AA27151@psi.com> I skimmed Ray's ASN.1 posting. Here's an initial comment. More may follow when I wake up :-) :-) > -- Delete Result Set APDUs > DeleteResultSetRequest ::=SEQUENCE{ > referenceId ReferenceId OPTIONAL, > deleteOperation [32] IMPLICIT INTEGER{ > list (0), > all (1)}, > resultSetList SEQUENCE OF ResultSetId OPTIONAL } > -- identification of the result sets to be deleted if operation is "li st" > > DeleteResultSetResponse ::={SEQUENCE > referenceId ReferenceId OPTIONAL, > deleteOperationStatus [0] IMPLICIT DeleteSetSt atu > s, > -- Reports the status for the entire delete operation. Values l imi > ted > -- to "success" or "failure-3" through "failure-9". Values of > -- "failure-7" and "failure-8" may be used only if operation is al > l > listStatuses [1] IMPLICIT ListStatuses OP TIO > NAL, > -- Must occur if operation is "list". Individual status values > -- limited to "success" through "failure-6". > numberNotDeleted [34] IMPLICIT INTEGER OPT ION > AL, > -- number of result sets the target failed to delete. Occurs on ly > -- if operation is "all". > bulkStatuses [35] IMPLICIT ListStatuse s > -- occurs if and only if DeleteSetStatus equals 8. Individual > -- statuses limited to "success" through "failure-6" > deleteMessage [36] IMPLICIT VisibleString OPTIONAL} > -- textual message concerning the delete operation. > ---- begin auxiliary definitions for delete > ListStatuses ::= IMPLICIT SEQUENCE OF SEQUENCE{ > ResultSetID, > DeleteSetStatus} > --DeleteSetStatus ::= [33] IMPLICIT INTEGER{ > success (0), > resultSetDidNotExist (1), > previouslyDeletedByTarget (2), > systemProblemAtTarget (3), > accessNotAllowed (4), > resource-control-at-origin (5), > resourceControl-at-target (6), > bulkDeleteNotSupported (7), > notAllRsltSetsDeletedOnBulkDlte (8) > notAllRequestedResultSetsDeleted (9)} > -- 7 and 8 used only if operation is "all". > ---- end auxiliary definitions for delete The new Delete operations seems a little more complex than it needs to be. Basically, what I think we want is for the DeleteRequest to contain 1) a indication of whether the operation requested is 'Delete-List' or 'Delete-All' 2) Optionally (if the requested operation is 'Delete-List') a list of result set ids identifying the result sets to be deleted. Then the DeleteResponse should contain 1) a delete status that either takes on the value 'Success' (whatever operation requested was successful) or 'Failure' (whatever operation requested was not successful -- for whatever reason). 2) Optionally (if the delete status was 'Failure'), the number of result sets not deleted. 3) Optionally (if the delete status was 'Failure' and the target supports returning such information) a list of individual delete set statuses. I guess what I'm saying is that I'm not sure why we need to distinguish between 'Delete-List' and 'Delete-All' in the response by going through complex acrobatics with OPTIONAL fields and comments that basically say "do X when Y but do P when Q". Specifically, I'd suggest: 1) Combining the 'listStatuses' and 'bulkStatuses' fields into one. "That which we call a rose by any other name ..." and all that: I see no reason to have two fields that are semantically identical (they both return individual statuses for failed deletes) for the two types of Delete operations. 2) Make the 'numberNotDeleted' field available for failed 'Delete-List' operations, as well as for 'Delete-All' operations. I believe the information is equally relevant in both cases. Actually, just to simplify things, I'd suggest you make it mandatory for all cases when deleteStatus is not "success". I'd also like to see deleteStatus be boolean valued, as opposed to enumerated, but that's just personal taste. Having it be enumerated is fine, and certainly does provide additional useful information. Wengyik ======================================================================== 489 Received: by NERVM (Mailer R2.07) id 5468; Fri, 25 Jan 91 07:59:53 EST Date: Fri, 25 Jan 91 12:13:09 +0200 Reply-To: Markku Savela Sender: "Z39.50 Implementors Workshop" From: Markku Savela Subject: Z39.50 ASN.1 To: "MARK HINNEBUSCH, FCLA" Hello, (I tried to mail this direct to bb.ray@rlg.bitnet, but it bounced :( Just for the fun of it I run the Z39.50 ASN.1 the posted description through the ASN.1 compiler I have here. Here are the changes I had to do before the module was mostly accepted. (I am not really doing anything on Z39.50 currently, just keeping eye on it... :) Some general comments about the changes I had to do: 1) Some mailer had mangled the message and broken some long lines. I had to fix these first (not showing in the diff here). 2) The module was enclosed into extra BEGIN ... END. pair. 3) Several lines had comment "----", which I had to change to "---", because the first two "--" start a comment and the next "--" end it. 4) Two occasion of form "Typename ::= IMPLICIT SEQUENCE ..." had to be changed to "Typename ::= SEQUENCE ..." (I don't think IMPLICIT can be used that way and my compiler said it was a syntax error; "Typename ::= [tag] IMPLICIT SEQUENCE ..." is syntactically correct also). 5) Typing errors here and there (missing ","'s, misplaced '}' and few valuenames typed with uppercase letters..) 6) Unfortunately, my ASN.1 compiler requires that all components of SEQUENCE and CHOICE have a valuename and I had to add those (e.g "SEQUENCE { A, B}" became "SEQUENCE {a A, b B}"). Many lines in the diff result from these changes. (And, my choice of name may not always be the most appropriate; the valuenames are not required by ASN.1, but maybe they should be added anyway..?) regards, -- Markku Savela (savela@tel.vtt.fi), Technical Research Centre of Finland Telecommunications Laboratory, Otakaari 7 B, SF-02150 ESPOO, Finland *** z3950.asn.orig Fri Jan 25 10:06:52 1991 --- z3950.asn Fri Jan 25 11:37:14 1991 *************** *** 12,18 **** presentRequest [24] IMPLICIT PresentRequest, presentResponse [25] IMPLICIT PresentResponse, deleteResultSetRequest [26] IMPLICIT DeleteResultSetRequest, ! deleteResultSetResponse [27] IMPLICIT DeleteResultSetResponse} accessControlRequest [28] IMPLICIT AccessControlRequest, accessControlResponse [29] IMPLICIT AccessControlResponse, resourceControlRequest [30] IMPLICIT ResourceControlRequest, --- 12,18 ---- presentRequest [24] IMPLICIT PresentRequest, presentResponse [25] IMPLICIT PresentResponse, deleteResultSetRequest [26] IMPLICIT DeleteResultSetRequest, ! deleteResultSetResponse [27] IMPLICIT DeleteResultSetResponse, accessControlRequest [28] IMPLICIT AccessControlRequest, accessControlResponse [29] IMPLICIT AccessControlResponse, resourceControlRequest [30] IMPLICIT ResourceControlRequest, *************** *** 20,26 **** -- new APDUs can be added in the future at the end of this list. ! - Initialization APDUs InitializeRequest ::=SEQUENCE {referenceId ReferenceId OPTIONAL, --- 20,26 ---- -- new APDUs can be added in the future at the end of this list. ! -- Initialization APDUs InitializeRequest ::=SEQUENCE {referenceId ReferenceId OPTIONAL, *************** *** 38,44 **** maximumRecordSize MaximumRecordSize, -- origin proposal for maximum record size (number of bytes). -- Value must be greater than or equal to preferredMessageSize. ! IdAuthentication [7] ANY OPTIONAL, -- information as required by the target to access the responding -- SRPM; syntax of this parameter to be defined by the target prior -- to communication. --- 38,44 ---- maximumRecordSize MaximumRecordSize, -- origin proposal for maximum record size (number of bytes). -- Value must be greater than or equal to preferredMessageSize. ! idAuthentication [7] ANY OPTIONAL, -- information as required by the target to access the responding -- SRPM; syntax of this parameter to be defined by the target prior -- to communication. *************** *** 58,64 **** -- does not agree on target values, it may abort the connection. maximumRecordSize MaximumRecordSize, -- target decision on the maximum record size ! Result [12] IMPLICIT BOOLEAN, -- result of the processing of the request at the target. -- reject = FALSE. Accept = TRUE; --- 58,64 ---- -- does not agree on target values, it may abort the connection. maximumRecordSize MaximumRecordSize, -- target decision on the maximum record size ! result [12] IMPLICIT BOOLEAN, -- result of the processing of the request at the target. -- reject = FALSE. Accept = TRUE; *************** *** 126,132 **** -- origin indicates whether or not to replace a previously created -- result set with the same name by the one that is constructed in -- this search. ! ResultSetName [17] IMPLICIT VisibleString, -- origin proposal for naming of the result set that is constructed -- if hits are found. If the target allows the origin to assign names -- to result sets, it uses this proposed name. If the target does --- 126,132 ---- -- origin indicates whether or not to replace a previously created -- result set with the same name by the one that is constructed in -- this search. ! resultSetName [17] IMPLICIT VisibleString, -- origin proposal for naming of the result set that is constructed -- if hits are found. If the target allows the origin to assign names -- to result sets, it uses this proposed name. If the target does *************** *** 160,176 **** RPNQuery ::= SEQUENCE{ attributeSetId OBJECT IDENTIFIER, -- identifies attribute set ! RPNStructure} RPNStructure ::= CHOICE { ! [0] Operand, ! [1] IMPLICIT SEQUENCE { ! RPNStructure, ! RPNStructure, ! Operator } } ! Operand ::= CHOICE {AttributesPlusTerm, ResultSetId} ! AttributesPlusTerm ::= [102] IMPLICIT SEQUENCE {AttributeList, Term} AttributeList ::= [44] IMPLICIT SEQUENCE OF AttributeElement Term ::= [45] IMPLICIT OCTET STRING --- 160,176 ---- RPNQuery ::= SEQUENCE{ attributeSetId OBJECT IDENTIFIER, -- identifies attribute set ! rpnStructure RPNStructure} RPNStructure ::= CHOICE { ! operand [0] Operand, ! rpnStructure [1] IMPLICIT SEQUENCE { ! rpn1 RPNStructure, ! rpn2 RPNStructure, ! operator Operator } } ! Operand ::= CHOICE {a AttributesPlusTerm, r ResultSetId} ! AttributesPlusTerm ::= [102] IMPLICIT SEQUENCE {a AttributeList, t Term} AttributeList ::= [44] IMPLICIT SEQUENCE OF AttributeElement Term ::= [45] IMPLICIT OCTET STRING *************** *** 182,190 **** and [0] IMPLICIT NULL, or [1] IMPLICIT NULL, and-not [2] IMPLICIT NULL} ! AttributeElement ::= IMPLICIT SEQUENCE ! {AttributeType, ! AttributeValue} AttributeType ::= [120] IMPLICIT INTEGER AttributeValue ::= [121] IMPLICIT INTEGER --- 182,190 ---- and [0] IMPLICIT NULL, or [1] IMPLICIT NULL, and-not [2] IMPLICIT NULL} ! AttributeElement ::= SEQUENCE ! {attributeType AttributeType, ! attributeValue AttributeValue} AttributeType ::= [120] IMPLICIT INTEGER AttributeValue ::= [121] IMPLICIT INTEGER *************** *** 287,293 **** searchStatus [22] IMPLICIT BOOLEAN, -- result of the processing of the request at the target IRPM. -- success = TRUE; failure = FALSE. ! resultSetStatus [26] IMPLICIT PartialResults OPTIONAL -- occurs if and only if search-status is FALSE indicates the presence -- and validity of the result set produced. presentStatus PresentStatus OPTIONAL, --- 287,293 ---- searchStatus [22] IMPLICIT BOOLEAN, -- result of the processing of the request at the target IRPM. -- success = TRUE; failure = FALSE. ! resultSetStatus [26] IMPLICIT PartialResults OPTIONAL, -- occurs if and only if search-status is FALSE indicates the presence -- and validity of the result set produced. presentStatus PresentStatus OPTIONAL, *************** *** 310,316 **** -- presentResults in the PresentResponse (within the limits given by -- the negotiated message and record size parameters), composed as -- specified by the element set names parameter below. ! ElementSetNames OPTIONAL, -- origin proposal for the composition of the records to be returned -- in the presentResults parameter in the PresentResponse preferredRecordSyntax PreferredRecordSyntax OPTIONAL} --- 310,316 ---- -- presentResults in the PresentResponse (within the limits given by -- the negotiated message and record size parameters), composed as -- specified by the element set names parameter below. ! elementSetNames ElementSetNames OPTIONAL, -- origin proposal for the composition of the records to be returned -- in the presentResults parameter in the PresentResponse preferredRecordSyntax PreferredRecordSyntax OPTIONAL} *************** *** 339,347 **** dataBaseOrSurDiagnostics [28] IMPLICIT SEQUENCE OF NamePlusRecord, nonSurrogateDiagnostic [130] IMPLICIT DiagRec} NamePlusRecord ::= SEQUENCE{ ! [0] IMPLICIT DatabaseName OPTIONAL, -- presence of this parameter is conditional. See xx.xx ! [1] CHOICE{ databaseRecord [1] DatabaseRecord, surrogateDiagnostic [2] DiagRec}} DatabaseRecord ::= EXTERNAL --- 339,347 ---- dataBaseOrSurDiagnostics [28] IMPLICIT SEQUENCE OF NamePlusRecord, nonSurrogateDiagnostic [130] IMPLICIT DiagRec} NamePlusRecord ::= SEQUENCE{ ! databaseName [0] IMPLICIT DatabaseName OPTIONAL, -- presence of this parameter is conditional. See xx.xx ! xx [1] CHOICE{ databaseRecord [1] DatabaseRecord, surrogateDiagnostic [2] DiagRec}} DatabaseRecord ::= EXTERNAL *************** *** 352,370 **** condition INTEGER, -- interpretation of condition is governed by values contained in -- definition identified by DiagnosticSetId. ! addinfo VisibleString, -- add'l information. -- end definition of record structure ! ---- begin definition of element set names ElementSetNames ::= [19] CHOICE{ generic [0] IMPLICIT ElementSetName, databaseSpecific [1] IMPLICIT SEQUENCE OF SEQUENCE{ ! DataBaseName, ! ElementSetName}} ElementSetName ::= [103] IMPLICIT VisibleString -- A target must always recognize the value "F" to mean "full record". -- end definition of element set name. ! ---- begin miscellaneous definitions for search and present APDUs NumberOfRecordsReturned ::= [24] IMPLICIT INTEGER NextResultSetPosition ::= [25] IMPLICIT INTEGER PresentStatus ::= [27] IMPLICIT INTEGER{ --- 352,370 ---- condition INTEGER, -- interpretation of condition is governed by values contained in -- definition identified by DiagnosticSetId. ! addinfo VisibleString} -- add'l information. -- end definition of record structure ! --- begin definition of element set names ElementSetNames ::= [19] CHOICE{ generic [0] IMPLICIT ElementSetName, databaseSpecific [1] IMPLICIT SEQUENCE OF SEQUENCE{ ! databaseName DatabaseName, ! elementSetName ElementSetName}} ElementSetName ::= [103] IMPLICIT VisibleString -- A target must always recognize the value "F" to mean "full record". -- end definition of element set name. ! --- begin miscellaneous definitions for search and present APDUs NumberOfRecordsReturned ::= [24] IMPLICIT INTEGER NextResultSetPosition ::= [25] IMPLICIT INTEGER PresentStatus ::= [27] IMPLICIT INTEGER{ *************** *** 375,382 **** partial-4 (4), failure (5)} PreferredRecordSyntax ::= [104] IMPLICIT OBJECT IDENTIFIER ! ---- end miscellaneous definitions for search and present APDUs ! ---- end auxiliary definitions for search and present APDUs -- -- Delete Result Set APDUs DeleteResultSetRequest ::=SEQUENCE{ --- 375,382 ---- partial-4 (4), failure (5)} PreferredRecordSyntax ::= [104] IMPLICIT OBJECT IDENTIFIER ! --- end miscellaneous definitions for search and present APDUs ! --- end auxiliary definitions for search and present APDUs -- -- Delete Result Set APDUs DeleteResultSetRequest ::=SEQUENCE{ *************** *** 387,393 **** resultSetList SEQUENCE OF ResultSetId OPTIONAL } -- identification of the result sets to be deleted if operation is "list" ! DeleteResultSetResponse ::={SEQUENCE referenceId ReferenceId OPTIONAL, deleteOperationStatus [0] IMPLICIT DeleteSetStatus, -- Reports the status for the entire delete operation. Values limited --- 387,393 ---- resultSetList SEQUENCE OF ResultSetId OPTIONAL } -- identification of the result sets to be deleted if operation is "list" ! DeleteResultSetResponse ::= SEQUENCE { referenceId ReferenceId OPTIONAL, deleteOperationStatus [0] IMPLICIT DeleteSetStatus, -- Reports the status for the entire delete operation. Values limited *************** *** 399,414 **** numberNotDeleted [34] IMPLICIT INTEGER OPTIONAL, -- number of result sets the target failed to delete. Occurs only -- if operation is "all". ! bulkStatuses [35] IMPLICIT ListStatuses -- occurs if and only if DeleteSetStatus equals 8. Individual -- statuses limited to "success" through "failure-6" deleteMessage [36] IMPLICIT VisibleString OPTIONAL} -- textual message concerning the delete operation. ! ---- begin auxiliary definitions for delete ! ListStatuses ::= IMPLICIT SEQUENCE OF SEQUENCE{ ! ResultSetID, ! DeleteSetStatus} ! --DeleteSetStatus ::= [33] IMPLICIT INTEGER{ success (0), resultSetDidNotExist (1), previouslyDeletedByTarget (2), --- 399,415 ---- numberNotDeleted [34] IMPLICIT INTEGER OPTIONAL, -- number of result sets the target failed to delete. Occurs only -- if operation is "all". ! bulkStatuses [35] IMPLICIT ListStatuses, -- occurs if and only if DeleteSetStatus equals 8. Individual -- statuses limited to "success" through "failure-6" deleteMessage [36] IMPLICIT VisibleString OPTIONAL} -- textual message concerning the delete operation. ! --- begin auxiliary definitions for delete ! ListStatuses ::= SEQUENCE OF SEQUENCE{ ! resultSetId ResultSetId, ! deleteSetStatus DeleteSetStatus} ! -- ! DeleteSetStatus ::= [33] IMPLICIT INTEGER{ success (0), resultSetDidNotExist (1), previouslyDeletedByTarget (2), *************** *** 417,427 **** resource-control-at-origin (5), resourceControl-at-target (6), bulkDeleteNotSupported (7), ! notAllRsltSetsDeletedOnBulkDlte (8) notAllRequestedResultSetsDeleted (9)} -- 7 and 8 used only if operation is "all". ! ---- end auxiliary definitions for delete ! ---- Access Control APDUs AccessControlRequest ::= SEQUENCE{ referenceId ReferenceId OPTIONAL, securityChallenge [37] IMPLICIT OCTET STRING} --- 418,428 ---- resource-control-at-origin (5), resourceControl-at-target (6), bulkDeleteNotSupported (7), ! notAllRsltSetsDeletedOnBulkDlte (8), notAllRequestedResultSetsDeleted (9)} -- 7 and 8 used only if operation is "all". ! --- end auxiliary definitions for delete ! --- Access Control APDUs AccessControlRequest ::= SEQUENCE{ referenceId ReferenceId OPTIONAL, securityChallenge [37] IMPLICIT OCTET STRING} *************** *** 428,455 **** AccessControlResponse ::= SEQUENCE{ referenceId ReferenceId OPTIONAL, securityChallengeResponse [38] IMPLICIT OCTET STRING} ! ---- Resource Control APDUs ResourceControlRequest ::= SEQUENCE{ referenceId ReferenceId OPTIONAL, ! SuspendedFlag [39] IMPLICIT BOOLEAN, -- "true" = suspended resourceReport [40] IMPLICIT ResourceReport OPTIONAL, partialResultsAvailable [41] IMPLICIT PartialResults OPTIONAL} ResourceControlResponse ::= SEQUENCE{ referenceId ReferenceId OPTIONAL, ! ContinueFlag [42] IMPLICIT BOOLEAN, -- "true" = "continue" ! ResultSetWanted [43] IMPLICIT BOOLEAN OPTIONAL} -- "true" = "result set wanted", required during a search if -- Continue flag is false; otherwise should not occur ! ---- Begin auxiliary definitions for access and resource control ResourceReport ::= SEQUENCE{ resourceReportId [1] IMPLICIT OBJECT IDENTIFIER, estimates [2] IMPLICIT SEQUENCE OF Estimate, message [3] IMPLICIT VisibleString} Estimate ::= SEQUENCE ! {EstimateType [1] IMPLICIT INTEGER -- from table, determined by -- ResourceReportId ! EstimateValue [2] IMPLICIT INTEGER -- the actual estimate} ! ---- End auxiliary definitions for resource and access control -- begin global auxiliary definitions --- 429,456 ---- AccessControlResponse ::= SEQUENCE{ referenceId ReferenceId OPTIONAL, securityChallengeResponse [38] IMPLICIT OCTET STRING} ! --- Resource Control APDUs ResourceControlRequest ::= SEQUENCE{ referenceId ReferenceId OPTIONAL, ! suspendedFlag [39] IMPLICIT BOOLEAN, -- "true" = suspended resourceReport [40] IMPLICIT ResourceReport OPTIONAL, partialResultsAvailable [41] IMPLICIT PartialResults OPTIONAL} ResourceControlResponse ::= SEQUENCE{ referenceId ReferenceId OPTIONAL, ! continueFlag [42] IMPLICIT BOOLEAN, -- "true" = "continue" ! resultSetWanted [43] IMPLICIT BOOLEAN OPTIONAL} -- "true" = "result set wanted", required during a search if -- Continue flag is false; otherwise should not occur ! --- Begin auxiliary definitions for access and resource control ResourceReport ::= SEQUENCE{ resourceReportId [1] IMPLICIT OBJECT IDENTIFIER, estimates [2] IMPLICIT SEQUENCE OF Estimate, message [3] IMPLICIT VisibleString} Estimate ::= SEQUENCE ! {estimateType [1] IMPLICIT INTEGER, -- from table, determined by -- ResourceReportId ! estimateValue [2] IMPLICIT INTEGER} -- the actual estimate ! --- End auxiliary definitions for resource and access control -- begin global auxiliary definitions ======================================================================== 321 Received: by NERVM (Mailer R2.07) id 4014; Thu, 24 Jan 91 19:06:49 EST Date: Thu, 24 Jan 91 07:14:19 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC Subject: Z39.50 appendices To: "MARK HINNEBUSCH, FCLA" APPENDIX A: Object Identifiers Assigned in This Standard This appendix is part of the standard. The following object identifier value has been assigned to this standard, ANSI-standard-Z39.50: { iso (1) member-body (2) US (840) ANSI-standard-Z39.50 (10003)} This standard assigns the following values at the level immediately subordinate to ANSI-standardZ39.50: 1 = application context 2 = abstract syntax 3 = attribute set 4 = diagnostic set 5 = record syntax 6 = resource report format A.1 Application Context This standard assigns the following object identifier for the application-context-definition 'basic-Z39.50-ac', contained in Appendix B: { iso member-body US ANSI-standard-Z39.50 application-context (1) basic-Z39.50-ac (1) } A.2 Abstract Syntax This standard assigns the following object identifier for the ASN.1 module, contained in section 4.1, defining the Z39.50 APDUs: { iso member-body US ANSI-standard-Z39.50 abstract-syntax (2) Z39.50-apdus (1) } Note: No object identifier is assigned by this standard for any transfer syntax for apdus. The transfer syntax results from the application of the ASN.1 Basic Encoding Rules (ISO 8825). For the purposes of Presentation Context negotiation, this syntax is identified by a pair of object identifiers, one for the abstract-syntax (Z39.50-apdus) and one for the basic encoding rules: { joint-iso-ccitt asn1 (1) basic-encoding (1) } A.3 Attribute set This standard assigns the following object identifier for the attribute-set definition 'bib-1', contained in Appendix C: { iso member-body US ANSI-standard-Z39.50 attribute-set (3) bib-1 (1) } A.4 Diagnostic Set This standard assigns the following object identifier for the diagnostic set definition contained in appendix D. { iso member-body US ANSI-standard-Z39.50 diagnostic-set (4) bib-1 (1)} A.5 Record Syntax Object identifier for Record syntaxes are contained in appendix E. A.6 Resource Report Format This standard assigns the following object identifier for the resource report format defined in appendix F. { iso member-body US ANSI-standard-Z39.50 resource-report-format (6) bib-1 (1)} APPENDIX B: Definition of Application Context basic-Z39.50-ac This appendix is part of the standard. This appendix defines the application context basic-Z39.50-ac. The object identifier for application context basic-Z39.50-ac is defined and registered in Appendix A. ANSI-standard-Z39.50 application context basic-Z39.50-ac, supports an application-entity that contains only the following two application service elements (ASEs): a) the Association Control service element (ACSE, ISO 8650), and b) the Z39.50 service element. APPENDIX C: Attribute Set bib-1 This appendix is part of the standard. This Appendix defines the attribute-set bib-1. The object identifier for attribute set bib-1 is defined and registered in Appendix A. When the value of AttributeSetId (within the RPNDefinition within the Search APDU) equals the object identifier for this attribute-set, then: a) AttributeType (within AttributeElement within AttributeList) takes values from the Attribute type table below, and b) AttributeValue takes values from the corresponding value table. Attribute-Type Values Attribute-type Value Use 1 Relation 2 Position 3 Structure 4 Truncation 5 Completeness 6 USE Values Use Value Use Value Personal-name 1 Date-of-acquisition 32 Corporate-name 2 Title-key 33 Conference-name 3 Title-collective 34 Title 4 Title-parallel 35 Title-series 5 Title-cover 36 Title-uniform 6 Title-added-title-page 37 ISBN 7 Title-caption 38 ISSN 8 Title-running 39 LC-card-number 9 Title-spine 40 BNB-card-number 10 Title-other-variant 41 BGF-number 11 Title-former 42 Local-number 12 Title-abbreviated 43 Dewey-classification 13 Title-expanded 44 UDC-classification 14 Subject-precis 45 Bliss-classification 15 Subject-rswk 46 LC-call-number 16 Subject-subdivision 47 NLM-call-number 17 Number-natl-bibliography 48 NAL-call-number 18 Number-legal-deposit 49 MOS-call-number 19 Number-govt-publication 50 Local-classification 20 Number-publisher-for-music 51 Subject-heading 21 Number-db 52 Subject-Rameau 22 USE Values (continued) Use Value Use Value BDI-index-subject 23 Number-local-call 53 INSPEC-subject 24 Code-language 54 MESH-subject 25 Code-geographic-area 55 PA-subject 26 Code-institution 56 LC-subject-heading 27 Name-and-title 57 RVM-subject-heading 28 Name-geographic 58 Local-subject-index 29 Place-publication 59 Date 30 CODEN 60 Date-of-publication 31 Microform-generation 61 Author-title 1000 NUC-code 1001 Combination-of-use 1002 System-control-number 1003 Subject-classification 1004 Record-type 1005 Name 1006 Relation Values Relation Value equal 3 greater than 5 greater or equal 4 less than 1 less than or equal 2 not equal 6 Position Values Structure Values Position Value Structure Value first in field 1 phrase 1 first in subfield 2 word 2 first in $a subfield 100 key 3 first in not $a subfield 101 year 4 any position in field 3 date 5 word list 6 Truncation Values Completeness Values Truncation Value Completeness Value do not truncation 100 incomplete subfield 1 right truncation 1 complete subfield 2 left truncation 2 complete field 3 left and right 3 process # in search arg 101 APPENDIX D: Diagnostic Set bib-1 This appendix is part of the Standard. This Appendix defines the diagnostic set bib-1. The object identifier for diagnostic set bib-1 is defined and registered in Appendix A. When the value of DiagnosticSetId (within DiagRec within the auxiliary definitions for Search Response and Present Response APDUs) equals the object identifier for this diagnostic set, then "condition" (within DiagRec) takes values from the "Condition" column in the table below. CONDITION MEANING TYPE 1 Permanent system error (1) 2 Temporary system error (1) 3 Unsupported search (2) 4 Terms only exclusion (stop) words (2) 5 Too many argument words (2) 6 Too many boolean operators (2) 7 Too many truncated words (2) 8 Too many incomplete subfields (2) 9 Truncated words too short (2) 10 Invalid format for rec no (search term) (2) 11 Too many characters in search statement (2) 12 Too many records retrieved (2) 13 Present request out-of-range (see note) (3) 14 System error in presenting records (4) 15 Record not authorized to be sent intersystem (4) 16 Record exceeds Preferred-message-size (4) 17 Record exceeds Maximum-record-size (4) 18 Result set not supported as a search term (2) 19 only single rslt set as srch trm supported (2) 20 only ANDing of a single result set as search term supported (2) 21 result set exists and replace indicator off (2) 22 result set naming not supported (2) 23 combination of specified databases not supported (2) 24 Element set names not supported (1) 25 Specified element set name not valid for specified database (1) 26 only a single element set name supported (1) 27 Result set no longer exists - unilaterally deleted by target (1) 28 Result set is in use (1) 29 One of the specified databases is locked (1) 30 Specified result set does not exist (1) 31 Resources exhausted - no results available (2) 32 Resources exhausted - unpredictable partial results available (2) 33 Resources exhausted - valid subset of results available (2) 100 Access-control failure (1) 101 Security challenge required but could not be issued - request terminated (1) 102 Security challenge required but could not be issued - record not included (4) 103 Terminated by negative continue response (1) TYPES: (1) May occur when search-status or present-status = "failure". (2) May occur only when search-status = "failure". (3) May occur only when present-status = "failure". (4) May occur only as a surrogate for a database record. NOTE: Condition 13 (present request out-of-range) applies when a present request is partially or wholly out-of-range, and includes the case when result-count is zero, but does not include the case where the specified result set does not exist. APPENDIX E: Record Syntaxes This appendix is part of the Standard. This appendix defines and registers object identifiers for record syntaxes. Names are assigned using the ASN.1 notation (ISO 8824) for OBJECT IDENTIFIER values: ANSI-Z39-50-2 DEFINITIONS ::= BEGIN Z39-50 OBJECT IDENTIFIER ::= { iso (1) member-body (2) US (840) ANSI- standard-Z39.50 (10003)} RecordSyntax OBJECT IDENTIFIER ::= { Z39-50 (5) } Unimarc ::= OBJECT IDENTIFIER { RecordSyntax (1) } Intermarc ::= OBJECT IDENTIFIER { RecordSyntax (2) } CCF ::= OBJECT IDENTIFIER { RecordSyntax (3) } US-MARC ::= OBJECT IDENTIFIER { RecordSyntax (10) } UK-MARC ::= OBJECT IDENTIFIER { RecordSyntax (11) } NORMARC ::= OBJECT IDENTIFIER { RecordSyntax (12) } LIBRISMARC ::= OBJECT IDENTIFIER { RecordSyntax (13) } DANMARC ::= OBJECT IDENTIFIER { RecordSyntax (14) } FINMARC ::= OBJECT IDENTIFIER { RecordSyntax (15) } MAB1 ::= OBJECT IDENTIFIER { RecordSyntax (16) } CAN/MARC ::= OBJECT IDENTIFIER { RecordSyntax (17) } SBN ::= OBJECT IDENTIFIER { RecordSyntax (18) } PICAMARC ::= OBJECT IDENTIFIER { RecordSyntax (19) } NOTES: (1) The above object identifiers are intended to be used as the values of PreferredRecordSyntax in Search and Present APDUs. (2) For the purposes of Presentation Context negotiation, record syntax is identified by a pair of object identifiers, one from the above list for the abstract-syntax and one for the transfer syntax. No object identifiers are assigned by this standard for transfer syntax for bibliographic records. However, an object identifiers has been assigned (outside of this standard) for the transfer-syntax for bibliographic records defined in ISO 2709: { iso standard 2709 transfer-syntax (4) character-encoding (1) } 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 within 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 current result for search 2 estimate of result at end of search if it completes 3 estimate of current result for present 4 estimate of result at end of present if it completes 5 processing time used by this command so far 6 estimated total processing time for command if allowed to complete 7 estimate of processing time used by association so far 8 estimate of cost for this command so far 9 estimate of cost for command if completed 10 estimate of cost for this association so far ======================================================================== 514 Received: by NERVM (Mailer R2.07) id 4084; Thu, 24 Jan 91 19:16:38 EST Date: Thu, 24 Jan 91 06:22:35 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC Subject: Z39.50 ASN.1 To: "MARK HINNEBUSCH, FCLA" -- ASN.1 Specification of Z39.50 APDUs BEGIN ANSIZ39-50-2 DEFINITIONS ::= BEGIN -- ANSIZ39-50-2 refers to the ANSI standard Z39.50 version 2 Z39-50-APDU ::= CHOICE {initRequest [20] IMPLICIT InitializeRequest, initResponse [21] IMPLICIT InitializeResponse, searchRequest [22] IMPLICIT SearchRequest, searchResponse [23] IMPLICIT SearchResponse, presentRequest [24] IMPLICIT PresentRequest, presentResponse [25] IMPLICIT PresentResponse, deleteResultSetRequest [26] IMPLICIT DeleteResultSetRequest, deleteResultSetResponse [27] IMPLICIT DeleteResultSetResponse} accessControlRequest [28] IMPLICIT AccessControlRequest, accessControlResponse [29] IMPLICIT AccessControlResponse, resourceControlRequest [30] IMPLICIT ResourceControlRequest, resourceControlResponse [31] IMPLICIT ResourceControlResponse} -- new APDUs can be added in the future at the end of this lis t. - Initialization APDUs InitializeRequest ::=SEQUENCE {referenceId ReferenceId OPTIONAL, protocolVersion ProtocolVersion, -- proposed version of the protocol to be used (see below). options Options, -- proposed set of services to be used preferredMessageSize PreferredMessageSize, -- origin proposal for the size of large messages (where message si ze -- is the sum of sizes, in number of bytes, of the records in an AP DU) -- that the target should normally use when presenting groups of -- records, however, the first record in a response is permitted to -- cause the message to exceed this size (see also maximumRecordSiz e -- below). maximumRecordSize MaximumRecordSize, -- origin proposal for maximum record size (number of bytes). -- Value must be greater than or equal to preferredMessageSize. IdAuthentication [7] ANY OPTIONAL, -- information as required by the target to access the responding -- SRPM; syntax of this parameter to be defined by the target prior -- to communication. implementationId ImplementationId OPTIONAL, implementationName ImplementationName OPTIONAL, implementationVersion ImplementationVersion OPTIONAL, userInformationField UserInformationField OPTIONAL} InitializeResponse ::= SEQUENCE {referenceId ReferenceId OPTIONAL, protocolVersion ProtocolVersion, options Options, preferredMessageSize PreferredMessageSize, -- target decision on the maximum APDU size (see description under -- InitializationRequest definition). Value is allowed to be differ ent -- from what origin proposed in the InitializationRequest; if origi n -- does not agree on target values, it may abort the connection. maximumRecordSize MaximumRecordSize, -- target decision on the maximum record size Result [12] IMPLICIT BOOLEAN, -- result of the processing of the request at the target. -- reject = FALSE. Accept = TRUE; implementationId ImplementationId OPTIONAL, implementationName ImplementationName OPTIONAL, implementationVersion ImplementationVersion OPTIONAL, userInformationField UserInformationField OPTIONAL} -- Auxiliary definitions for Initialization APDUs ProtocolVersion ::= [3] IMPLICIT BIT STRING -- represents a string of Boolean values, each value representing a -- version. The first value set to 1 indicates version 1 is availab le, -- the second value set to 1 indicates version 2 is available, -- and so on. Values higher than the highest known version should -- be ignored. Both the Initialize and Initialize Response APDUs -- include a value string corresponding to the supported versions. -- The highest common version is selected for use. If there are no -- versions in common, the Initialize Response APDU should indicate -- a value of "reject" for the parameter Result. Options ::= [4] IMPLICIT BIT STRING {search (0), present (1),delSet (2 ), resourceCtrl (3), accessCtrl (4)} -- In InitializeRequest, for search, present and delete, -- bit ON indicates initiator does request use of service; for resource -- contrl and access control, bit ON indicated indicated initiator will -- support service. -- For InitializeResponse, for search, present and delete, bit ON -- indicates target will support service; for resource control and -- access control, bit ON indicated target requests service. -- For extensibility of the protocol, additional bits set should not be -- considered to be an error on received InitializeRequest. PreferredMessageSize ::= [5] IMPLICIT INTEGER MaximumRecordSize ::= [6] IMPLICIT INTEGER ImplementationId ::= [110] IMPLICIT VisibleString ImplementationName ::= [111] IMPLICIT VisibleString ImplementationVersion ::= [112] IMPLICIT VisibleString -- these three implementation parameters are provided solely for the -- convenience of implementors needing to distinguish implementations. -- They shall not be the subject of conformance tests. UserInformationField ::= [11] EXTERNAL -- additional information, not defined in this standard. -- end auxiliary definitions for initialization APDUs -- Search APDUs SearchRequest ::= SEQUENCE{ referenceId ReferenceId OPTIONAL, smallSetUpperBound [13] IMPLICIT INTEGER, -- if the number of hits is less than or equal to this number, all -- records are to be returned in the SearchResponse (within the -- limits given by the negotiated preferredMessage- and -- maximumRecordSize), composed in the way specified by the -- smallSetElementSetNames parameter below. May be zero. largeSetLowerBound [14] IMPLICIT INTEGER, -- if the number of hits is equal to or greater than this number, n o -- records are to be returned. LargeSetLowerBound must be greater t han -- smallSetUpperBound." Greater than SmallSetUpperBound. mediumSetPresentNumber [15] IMPLICIT INTEGER, -- maximum number of records to be returned in the SearchResponse -- if the number of hits is between largeSetLowerBound and -- smallSetUpperBound (again within the limits given -- by the message and record size parameters), composed as -- specified by mediumSetRecordElementSetNames replaceIndicator [16] IMPLICIT BOOLEAN, -- origin indicates whether or not to replace a previously created -- result set with the same name by the one that is constructed in -- this search. ResultSetName [17] IMPLICIT VisibleString, -- origin proposal for naming of the result set that is constructed -- if hits are found. If the target allows the origin to assign na mes -- to result sets, it uses this proposed name. If the target does -- not support named result sets it returns an error diagnostic. databaseNames [18] IMPLICIT SEQUENCE OF DatabaseName, -- database(s) in which the search will be performed. smallSetElementSetNames [100] IMPLICIT ElementSetNames OPTIONAL, -- origin proposal for the composition of the records in the small -- set (see above under smallSetUpperBound). mediumSetElementSetNames [101] IMPLICIT ElementSetNames OPTIONAL, -- origin proposal for the composition of the records in the medium -- set (see above under mediumSetPresentNumber). preferredRecordSyntax PreferredRecordSyntax OPTIONAL, -- origin proposal for the abstract syntax of the database records -- to be returned in the SearchResponse. Values subject to -- registration. query [21] Query} -- the search argument (see description below). -- query definition Query ::= CHOICE {type-0 [0] ANY, type-1 [1] IMPLICIT RPNQuery, type-2 [2] OCTET STRING} -- the search argument contained in the SearchRequest. Three types -- are defined: -- a) A type-0 query may be used only when the origin and target -- have an a priori agreement outside of this standard as to -- form of quert acceptable to the target. -- b) type-1 is the Reverse Polish Notation (RPN) query (see belo w). -- c) type-2 is the ISO8777 type query, specified in ISO 8777. RPNQuery ::= SEQUENCE{ attributeSetId OBJECT IDENTIFIER, -- identifies attribute set RPNStructure} RPNStructure ::= CHOICE { [0] Operand, [1] IMPLICIT SEQUENCE { RPNStructure, RPNStructure, Operator } } Operand ::= CHOICE {AttributesPlusTerm, ResultSetId} AttributesPlusTerm ::= [102] IMPLICIT SEQUENCE {AttributeList, Term} AttributeList ::= [44] IMPLICIT SEQUENCE OF AttributeElement Term ::= [45] IMPLICIT OCTET STRING -- the type OCTET STRING is used to enable the inclusion of multiby te -- character representations which the types CharacterString and -- VisibleString might impose on graphic character repertoire. Operator ::= [46] CHOICE{ and [0] IMPLICIT NULL, or [1] IMPLICIT NULL, and-not [2] IMPLICIT NULL} AttributeElement ::= IMPLICIT SEQUENCE {AttributeType, AttributeValue} AttributeType ::= [120] IMPLICIT INTEGER AttributeValue ::= [121] IMPLICIT INTEGER -- AttributeType and AttributeValue interpretation is governed by t he -- values contained in the definition identified by AttributeSetId -- Notes: -- 1. "query" is recursively defined; it is either -- (a) "operand" , or -- (b) "argument + argument + operator". -- -- In case (b), each occurence of "argument" can be replaced by either (a) -- or (b) and so on. -- -- A structure composed of operators and operands conforms to the type-1 -- query syntax if and only if it is possible, by repeatedly replacing -- occurrences of (b) with (a), to reduce the structure to (a). -- -- 2. "operand" is either (a) AttributesPlusTerm, or (b) ResultSetId. In -- either case it represents a set of database records. For (a) it is the s et -- of database records obtained by evaluating the specified attribute-list -- and term against the collection of databases specified in the request. -- For (b) it is the set of database records represented by the result set -- for which ResultSetId was specified as the value of the parameter -- ResultSetName in the current or a previous Search request. -- -- 3. An example of an attribute-list for use with the Type-1 query is given in --Rules for evaluation of the query are as follows: -- -- Evaluation of operands and operators is illustrated by the use of a stack. -- The query is evaluated left-to-right. Each query-term is one of the following : -- (1) AttributesPlusTerm -- (2) ResultSetId -- (3) Operator -- -- Whenever (1) is encountered, it is evaluated against the collection of -- databases specified in the Search request, and the result is put on the -- stack. -- -- Whenever (2) is encountered, it is put on the stack. -- -- Whenever (3) is encountered, the last two items (i.e. sets, see note 2 -- that have been put on the stack are pulled off and the operator is applie d -- as follows: -- -- - if Operator is AND, the result is the intersection of the two sets, -- -- - if Operator is OR, the result is the union of the two sets, -- -- - if Operator is AND-NOT, the result is the set of elements in the -- first set which are not in the second set. -- The resulting set is then put on the stack. -- -- When evaluation of the query is complete (i.e. all query-terms have been -- processed) there will be one item remaining on the stack (otherwise the -- query is in error) which is the result of the query. -- -- -- Examples: -- -- The following examples illustrate query evaluation. In these examples, D -- represents the collection of databases specified in the Search request, -- R represents a Result-set-id, and A, B, and C represent attribute-list/te rm -- combinations such as "subject = dogs". -- -- 1. Query = A -- -- Result: the records in D for which A is true -- -- 2. Query = A B C AND OR -- -- Result: the records in D for which both B and C are true, o r -- A is true -- 3. Query = A B AND C OR -- -- Result: the records in D for which both A and B are true, o r -- C is true -- -- 4. Query = R A AND -- -- Result: the records in D for which both (1) A is true, and ( 2) -- which are also in result set R -- -- 5. Query = R A OR -- -- Result: the records in D for which A is true, together wit h -- the records in result set R -- end query definition -- SearchResponse ::= SEQUENCE{ referenceId ReferenceId OPTIONAL, resultCount [23] IMPLICIT INTEGER, -- number of hits resulting from the search. numberOfRecordsReturned NumberOfRecordsReturned, -- number of records in the searchResults below. nextResultSetPosition NextResultSetPosition, -- the ordinal number in the result set of the record appearing -- directly after the last record in the searchResults below. searchStatus [22] IMPLICIT BOOLEAN, -- result of the processing of the request at the target IRPM. -- success = TRUE; failure = FALSE. resultSetStatus [26] IMPLICIT PartialResults OPTIONAL -- occurs if and only if search-status is FALSE indicates the prese nce -- and validity of the result set produced. presentStatus PresentStatus OPTIONAL, -- occurs if and only if search-status is TRUE indicates the presen ce -- and validity of the records appearing in the searchResults (see -- description below). databaseOrDiagnosticRecords Records OPTIONAL} -- the records (diagnostic and/or bibliographic) resulting from the -- search (see description below). -- PresentRequest ::= SEQUENCE{ referenceId ReferenceId OPTIONAL, resultSetId ResultSetId, -- identification of the result set from which to retrieve records resultSetStartPoint [30] IMPLICIT INTEGER, -- ordinal number in the result set of the first record to appear i n -- the presentResults in the PresentResponse. numberOfRecordsRequested [29] IMPLICIT INTEGER, -- specifies the maximum number of records to be returned in the -- presentResults in the PresentResponse (within the limits given b y -- the negotiated message and record size parameters), composed as -- specified by the element set names parameter below. ElementSetNames OPTIONAL, -- origin proposal for the composition of the records to be returne d -- in the presentResults parameter in the PresentResponse preferredRecordSyntax PreferredRecordSyntax OPTIONAL} -- origin proposal for the abstract syntax of the database records -- to be returned in the presentResults in the PresentResponse. -- values subject to registration, at present by means of -- specification in Appendix xx. -- PresentResponse ::= SEQUENCE{ referenceId ReferenceId OPTIONAL, numberOfRecordsReturned NumberOfRecordsReturned, -- number of records returned in the presentResults below. nextResultSetPosition NextResultSetPosition, -- the ordinal number in the result set of the record appearing -- directly after the last record in the presentResults below. presentStatus PresentStatus, -- indicates the presence and validity of the records databaseOrDiagnosticRecords Records OPTIONAL} -- the presented records -- -- -- begin auxiliary definitions for search and present APDUs -- -- begin definition of record structure Records ::= CHOICE{ dataBaseOrSurDiagnostics [28] IMPLICIT SEQUENCE OF NamePlusReco rd, nonSurrogateDiagnostic [130] IMPLICIT DiagRec} NamePlusRecord ::= SEQUENCE{ [0] IMPLICIT DatabaseName OPTIONAL, -- presence of this parameter is conditional. See x x.xx [1] CHOICE{ databaseRecord [1] DatabaseRecord, surrogateDiagnostic [2] DiagRec}} DatabaseRecord ::= EXTERNAL -- the database record syntax is defined outside of this standard. -- For bibliographic data, USMARC is a prime example. DiagRec ::= SEQUENCE{ diagnosticSetId OBJECT IDENTIFIER, condition INTEGER, -- interpretation of condition is governed by values contained in -- definition identified by DiagnosticSetId. addinfo VisibleString, -- add'l information. -- end definition of record structure ---- begin definition of element set names ElementSetNames ::= [19] CHOICE{ generic [0] IMPLICIT ElementSetName, databaseSpecific [1] IMPLICIT SEQUENCE OF SEQUENCE{ DataBaseName, ElementSetName}} ElementSetName ::= [103] IMPLICIT VisibleString -- A target must always recognize the value "F" to mean "full record ". -- end definition of element set name. ---- begin miscellaneous definitions for search and present APDUs NumberOfRecordsReturned ::= [24] IMPLICIT INTEGER NextResultSetPosition ::= [25] IMPLICIT INTEGER PresentStatus ::= [27] IMPLICIT INTEGER{ success (0), partial-1 (1), partial-2 (2), partial-3 (3), partial-4 (4), failure (5)} PreferredRecordSyntax ::= [104] IMPLICIT OBJECT IDENTIFIER ---- end miscellaneous definitions for search and present APDUs ---- end auxiliary definitions for search and present APDUs -- -- Delete Result Set APDUs DeleteResultSetRequest ::=SEQUENCE{ referenceId ReferenceId OPTIONAL, deleteOperation [32] IMPLICIT INTEGER{ list (0), all (1)}, resultSetList SEQUENCE OF ResultSetId OPTIONAL } -- identification of the result sets to be deleted if operation is "list" DeleteResultSetResponse ::={SEQUENCE referenceId ReferenceId OPTIONAL, deleteOperationStatus [0] IMPLICIT DeleteSetStatu s, -- Reports the status for the entire delete operation. Values limi ted -- to "success" or "failure-3" through "failure-9". Values of -- "failure-7" and "failure-8" may be used only if operation is al l listStatuses [1] IMPLICIT ListStatuses OPTIO NAL, -- Must occur if operation is "list". Individual status values -- limited to "success" through "failure-6". numberNotDeleted [34] IMPLICIT INTEGER OPTION AL, -- number of result sets the target failed to delete. Occurs only -- if operation is "all". bulkStatuses [35] IMPLICIT ListStatuses -- occurs if and only if DeleteSetStatus equals 8. Individual -- statuses limited to "success" through "failure-6" deleteMessage [36] IMPLICIT VisibleString OPTIONAL} -- textual message concerning the delete operation. ---- begin auxiliary definitions for delete ListStatuses ::= IMPLICIT SEQUENCE OF SEQUENCE{ ResultSetID, DeleteSetStatus} --DeleteSetStatus ::= [33] IMPLICIT INTEGER{ success (0), resultSetDidNotExist (1), previouslyDeletedByTarget (2), systemProblemAtTarget (3), accessNotAllowed (4), resource-control-at-origin (5), resourceControl-at-target (6), bulkDeleteNotSupported (7), notAllRsltSetsDeletedOnBulkDlte (8) notAllRequestedResultSetsDeleted (9)} -- 7 and 8 used only if operation is "all". ---- end auxiliary definitions for delete ---- Access Control APDUs AccessControlRequest ::= SEQUENCE{ referenceId ReferenceId OPTIONAL, securityChallenge [37] IMPLICIT OCTET STRING} AccessControlResponse ::= SEQUENCE{ referenceId ReferenceId OPTIONAL, securityChallengeResponse [38] IMPLICIT OCTET STRING} ---- Resource Control APDUs ResourceControlRequest ::= SEQUENCE{ referenceId ReferenceId OPTIONAL, SuspendedFlag [39] IMPLICIT BOOLEAN, -- "true" = suspende d resourceReport [40] IMPLICIT ResourceReport OPTIONAL, partialResultsAvailable [41] IMPLICIT PartialResults OPTIONAL} ResourceControlResponse ::= SEQUENCE{ referenceId ReferenceId OPTIONAL, ContinueFlag [42] IMPLICIT BOOLEAN, -- "true" = "continu e" ResultSetWanted [43] IMPLICIT BOOLEAN OPTIONAL} -- "true" = "result set wanted", required during a search if -- Continue flag is false; otherwise should not occur ---- Begin auxiliary definitions for access and resource control ResourceReport ::= SEQUENCE{ resourceReportId [1] IMPLICIT OBJECT IDENTIFIER, estimates [2] IMPLICIT SEQUENCE OF Estimate, message [3] IMPLICIT VisibleString} Estimate ::= SEQUENCE {EstimateType [1] IMPLICIT INTEGER -- from table, determined by -- ResourceReportId EstimateValue [2] IMPLICIT INTEGER -- the actual estimate} ---- End auxiliary definitions for resource and access control -- begin global auxiliary definitions ReferenceId ::= [2] IMPLICIT OCTET STRING -- value provided by the service originator in the Request APDU, -- target required to send it back unaltered in the corresponding -- Response APDU. DatabaseName ::= [105] IMPLICIT VisibleString ResultSetId ::= [31] IMPLICIT VisibleString PartialResults ::= INTEGER {subset (1), interim (2), none (3)} -- end global auxiliary definitions END -- ANSIZ39-50-2 END. ======================================================================== 14 Received: by NERVM (Mailer R2.07) id 7669; Wed, 23 Jan 91 14:55:01 EST Date: Wed, 23 Jan 91 11:52:53 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC Subject: Second draft of Z39.50 Version 2 To: "MARK HINNEBUSCH, FCLA" A second draft of version 2 of Z39.50 will be completed in time for the meeting next week and distributed there. I cannot distribute it by e-mail because of the length, formatting, and annotations. However, I will try (in the next few days) to transmit (1) the ASN.1 section, and (2) the appendices, which are completely revised. ======================================================================== 28 Received: by NERVM (Mailer R2.07) id 3595; Tue, 22 Jan 91 17:03:58 EST Date: Tue, 22 Jan 91 17:04:55 EST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ralph LeVan Subject: Re: Z39.50 over TCP X-To: z3950iw%nervm.nerdc.ufl.edu@cunyvm.cuny.edu To: "MARK HINNEBUSCH, FCLA" > Anyway, conceptually it isn't very difficult to run Z39.50 over TCP. > Doing the work is a different matter, of course ... :-) :-). And getting > all the different implementations to interoperate if each implementation > adopts a different solution to the problem could prove ... interesting :-). > > So, would there be sufficient interest within the ZIG for a subset to do > something together as a ZIG subactivity ('something' meaning implementation, > of course)? This sounds very interesting to me. As I said before, the ISO stack is my biggest impediment to interoperability. I've mentioned this to my management, and have even been given permission to work on it. 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 ======================================================================== 125 Received: by NERVM (Mailer R2.07) id 8090; Mon, 21 Jan 91 14:07:51 EST Date: Mon, 21 Jan 91 14:03:28 -0500 Reply-To: z3950iw@nervm.nerdc.ufl.edu Sender: "Z39.50 Implementors Workshop" From: yeongw@PSI.COM Subject: Z39.50 over TCP X-To: z3950iw@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" [Apologies to those who are not interested in running Z39.50 over TCP, ever. Unfortunately, I don't know how else to contact the people who do] I have seen a number of messages on this list recently regarding running Z39.50 over TCP. Since this happens to be what I'm primarily interested in, I was wondering if there would be any interest in doing things together from the start, instead of each of us implementing our own method of running Z39.50 over TCP and then trying to interoperate later. Looking at the Z39.50 protocol specification, I've come to the conclusion that Z39.50 basically requires three services of the network stack it sits on top of: 1) A reliable bit pipe. Z39.50 doesn't have any facilities for sequencing, retransmission or message verification. Instead, it assumes that the bytes it shoves into the pipe will all come out at the other end, in the same order they went in. 2) Multiplexing Z39.50 has no facilities to multiplex multiple connections, so the underlying stack has to do it. 3) Transfer notation negotiation There is a need for a client and target to come to a mutual agreement as to how the data abstractions in Z39.50 (the PDUs, the records) are represented for transmission "across the wire". In the OSI stack, (3) is taken care of by Presentation services, (2) by Session services, and (1) partially by Session services and partially by using a reliable transport. However, any network stack that can provide functionality equivalent to (1) - (3) will do. In the context of TCP, there are three ways to provide this functionality, more or less: 1) Implement presentation and session layers on top of TCP This is exactly what ISODE does. The concept is explained in RFC 1006. Since presentation and session layers are implemented on top of TCP, (2) and (3) are available. (1) is also available since TCP provides reliability and sequencing guarantees. 2) Provide the illusion of presentation and session services. The idea here is to implement functionality equivalent to that required of the presentation and session layers, by Z39.50 without actually doing a 'full blown' implementation of the presentation and session layers: only the functionality required by Z39.50 (in this case) is implemented. A possible approach to this is described in RFC 1085. The idea here is to do as little work as possible while making it appear that Z39.50 actually has presentation and session layers underneath. By definition, (2) and (3) are available in this approach. In fact, they're the only presentation and session services available :-) :-). (1) is provided by TCP since it's reliable. 3) "Do-it-yourself" functionality. (1) - (3) are somehow provided through a collection of kludges, interposing software layers, and tailoring the Z39.50 implementation. (1) is "no-brainer" again, since TCP is reliable. (2) is obtained 'by default' as long as the standard programming interfaces are used and the Z39.50 implementation doesn't insist on directly calling the actual functions that implement TCP. In the 'sockets' abstraction, you multiplex on the socket. Similarly with 'streams': don't hold me to this (since I'm not really up on SVID), but I think you multiplex on what's called the 'transport control block' here. (3) is a toughie. You can write an interposing software layer to do the negotiation. Or you can 'cheat' and recognize that it will almost always be the case that there is a one-to-one mapping between data abstractions and the format of the byte stream that gets sent. For example, realistically, there is only one way of encoding ASN.1 for transmission: with the BER. Similarly, for any given record format, how many people are going to support more than one way of representing the format for transmission. As illustration, how many people will support more than one way of encoding MARC (the record format) for transmission? Anyway, conceptually it isn't very difficult to run Z39.50 over TCP. Doing the work is a different matter, of course ... :-) :-). And getting all the different implementations to interoperate if each implementation adopts a different solution to the problem could prove ... interesting :-). So, would there be sufficient interest within the ZIG for a subset to do something together as a ZIG subactivity ('something' meaning implementation, of course)? [Believe it or not, I *do* have better things to do than continually propose cooperative projects :-) :-), the fact that I have now proposed two in succession notwithstanding. It just turned out that way.] Wengyik ======================================================================== 22 Received: by NERVM (Mailer R2.07) id 2136; Fri, 18 Jan 91 16:45:40 EST Date: Fri, 18 Jan 91 12:11:19 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Wayne Davison Subject: re:Interoperable Z39.50 Implementations anyone? To: "MARK HINNEBUSCH, FCLA" REPLY TO 01/18/91 10:39 FROM Z3950IW@NERVM.BITNET "Z39.50 Implementors Workshop": re:Interoperable Z39.50 Implementations anyone? There has been quite a bit of consideration of RDA. The National Library of Canada had one of their consultants do a detailed study on this topic. And the possibility of using RDA was considered in a previous ballot on ISO DIS 10162 and 10163 (SR). It is important to remember that RDA is incomplete, and cannot be used, without a 'Specialization.' The only specialization that currently exists is for SQL. Most of us who have looked at this question have determined that while we could develop a Z39.50 specialization for RDA, we would loose more that we would gain in the process. To: Z3950IW@NERVM.BITNET ======================================================================== 34 Received: by NERVM (Mailer R2.07) id 1011; Fri, 18 Jan 91 13:35:08 EST Date: Fri, 18 Jan 91 13:35:14 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Joe Zeeman Subject: re:Interoperable Z39.50 Implementations anyone? X-To: z3950iw@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" I'm beginning to think that X.500 might be both interesting and useful to provide a kind of "bibliographic white pages" - what I've referred to before as "known item searching". The kind of scenario is someone who's identified the item they want (using Z39.50 to access Index Medicus or whatever) and now wants to know the nearest library that holds that item. To accomplish this using Z39.50 will require building much of the functionality that X.500 already offers into your application. Kind of "build your own X.500 over Z39.50". So it might be just as easy to use X.500 directly. After all, the result sets should be nice and small, and there is only a small set of search attributes to worry about-- ISDNs and other standard numbers, author-titles, perhaps even search acronyms. However, the thought of building both Z39.50 AND X.500 interfaces to all these database systems is horrible. Interesting, too, that nobody has mentioned RDA as an alternative to Z39.50. Joe Zeeman Software Kinetics Ltd. "my own thoughts entirely" > > > ======================================================================== 17 Received: by NERVM (Mailer R2.07) id 8711; Thu, 17 Jan 91 17:01:48 EST Date: Thu, 17 Jan 91 14:03:11 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Wayne Davison Subject: Re: Interoperable Z39.50 Implementations anyone? X-To: z3950iw@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" REPLY TO 01/17/91 13:27 FROM Z3950IW@NERVM.NERDC.UFL.EDU: Re: Interoperable Z39.50 Implementations anyone? I am familiar with proposals to use X.500 for information retrieval, but I know nothing about using CMIP for this purpose. Can you supply additional information? To: Z3950IW@NERVM.NERDC.UFL.EDU ======================================================================== 24 Received: by NERVM (Mailer R2.07) id 8551; Thu, 17 Jan 91 16:33:01 EST Date: Thu, 17 Jan 91 16:34:11 -0500 Reply-To: z3950iw@nervm.nerdc.ufl.edu Sender: "Z39.50 Implementors Workshop" From: yeongw@SPARTACUS.PSI.COM Subject: Re: Interoperable Z39.50 Implementations anyone? To: "MARK HINNEBUSCH, FCLA" In-Reply-To: Your message of Thu, 17 Jan 91 14:16:28 -0500. <9101171923.AA26234@psi.com> > I didn't think there was any question about it. We have all agreed to > implement to version 2 of Z39.50. It should be pretty much as specified > in the draft of Sept. 90 (ZIG 010), and varies VERY LITTLE from 10162/10163. > I didn't get that impression. I guess all the talk about Z39.50 extensions and the lack of talk about implementation problems on the mailing list threw me off. Sorry. ... Wengyik will now go away and you will be returned to your regularly scheduled discussions ... :-) :-) Wengyik ======================================================================== 24 Received: by NERVM (Mailer R2.07) id 8493; Thu, 17 Jan 91 16:23:30 EST Date: Thu, 17 Jan 91 16:24:45 -0500 Reply-To: z3950iw@nervm.nerdc.ufl.edu Sender: "Z39.50 Implementors Workshop" From: yeongw@SPARTACUS.PSI.COM Subject: Re: Interoperable Z39.50 Implementations anyone? To: "MARK HINNEBUSCH, FCLA" In-Reply-To: Your message of Thu, 17 Jan 91 11:44:54 -0800. <9101171940.AA26673@psi.com> > Z39.50 over CMIP and/or X.500? How? WHY? > No, not Z39.50 *over* CMIP or X.500. CMIP or X.500 *replacing* Z39.50 The basic rationale is that a protocol that has search/retrieve capabilities is needed to solve a problem. Z39.50, CMIP, X.500 (and electronic mail systems and ftp/telnet, to a much lesser extent) all have search and retrieve capabilities. ... Therefore they are all candidate solutions to the problem. Wengyik ======================================================================== 17 Date: Thu, 17 Jan 91 15:47:26 EST From: "Mark Hinnebusch, FCLA" Subject: Re: Interoperable Z39.50 Implementations anyone? To: "Z39.50 Implementors Workshop" In-Reply-To: Message of Thu, 17 Jan 91 12:45:17 PST from I don't think that anyone in this group has debated CMIP or X.500 as a replacement for Z39.50. However, a number of others, in other arenas, have talked about using them for what they view as essentially the same function. In most cases, they are unaware of Z39.50 and are not in the library community. Perhaps Yengyik would like to comment, but I don't think that he was suggesting X.500 or CMIP but merely referencing the interest in other quarters. I will say that this email stuff doesn't clarify communication like I would have thought on first glance. Maybe that is a good excuse for continuing to meet in exotic places like Oakland :-) ======================================================================== 15 Received: by NERVM (Mailer R2.07) id 7947; Thu, 17 Jan 91 15:45:33 EST Date: Thu, 17 Jan 91 12:45:17 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Wayne Davison Subject: Re: Interoperable Z39.50 Implementations anyone? To: "MARK HINNEBUSCH, FCLA" REPLY TO 01/17/91 12:38 FROM Z3950IW@NERVM.BITNET "Z39.50 Implementors Workshop": Re: Interoperable Z39.50 Implementations anyone? I understand about the TCP/IP implementations, but that is a different issue from X.500 and CMIP. To: Z3950IW@NERVM.BITNET ======================================================================== 20 Date: Thu, 17 Jan 91 15:26:49 EST From: "Mark Hinnebusch, FCLA" Subject: Re: Interoperable Z39.50 Implementations anyone? To: "Z39.50 Implementors Workshop" In-Reply-To: Message of Thu, 17 Jan 91 11:44:54 PST from From the very beginning, the group has divided into two subgroups, one planning on OSI, cause that's the way it will be, and one planning on TCP/IP, cause that's the way it is. The TCP/IP group have committed to building the necessary session and presentation functions over which to run their Z39.50s. We all recognize that these groups will not be able to interoperate with each other initially. An application layer bridge would perform the necessary transfer, however. Over the long term, since the Internet is going dual protocol, we are all committed to Z39.50 over OSI. p.s. I think building the bridge would be kinda fun. I plan on doing a TCP/IP add-on after I have done OSI. Then, just for the fun of it, one over SNA in case I ever want to talk to someone (like a PC-based agent on my current SNA network) that way. ======================================================================== 21 Received: by NERVM (Mailer R2.07) id 7647; Thu, 17 Jan 91 14:42:13 EST Date: Thu, 17 Jan 91 11:44:54 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Wayne Davison Subject: Interoperable Z39.50 Implementations anyone? X-To: z3950iw@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" REPLY TO 01/17/91 07:05 FROM Z3950IW@NERVM.NERDC.UFL.EDU: Interoperable Z39.50 Implementations anyone? Z39.50 over CMIP and/or X.500? How? WHY? I don't see how continuing to identify additional supporting stacks is going to help us develop interworking implementations. Z39.50 was designed to run over ISO 8650 (connection-oriented ACSE), ISO 8823 (connection-oriented Presentation) and ISO 8327 (connection-oriented Session). Why don't we just do that? To: Z3950IW@NERVM.NERDC.UFL.EDU ======================================================================== 18 Date: Thu, 17 Jan 91 14:16:28 EST From: "Mark Hinnebusch, FCLA" Subject: Re: Interoperable Z39.50 Implementations anyone? To: z3950iw@nervm.nerdc.ufl.edu In-Reply-To: Message of Thu, 17 Jan 91 10:02:09 -0500 from I didn't think there was any question about it. We have all agreed to implement to version 2 of Z39.50. It should be pretty much as specified in the draft of Sept. 90 (ZIG 010), and varies VERY LITTLE from 10162/10163. Personally, I have been quiet since I don't know when I will have code ready, not because I don't intend to go with Version 2 the way it is. I intend that my implementation will be general enough to support new element sets, attribute sets, resource reports, diagnostic sets, etc., as they are developed. The proximity operation is a little more basic but can be added later and will undoubtably be structured so that interoperability with systems not offering proximity in the type 1 query will not be compromised. ======================================================================== 22 Received: by NERVM (Mailer R2.07) id 6863; Thu, 17 Jan 91 12:15:55 EST Date: Thu, 17 Jan 91 12:16:55 EST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ralph LeVan Subject: Re: Interoperable Z39.50 Implementations anyone? X-To: z3950iw%nervm.nerdc.ufl.edu@cunyvm.cuny.edu To: "MARK HINNEBUSCH, FCLA" I really want to say yes. (In fact, I have said yes in the past.) Implementing z39.50 is really straightforward for us. It's that damn stack that it depends on that scares me. I don't have the resources to get that going, and have been unwilling to ask for outside (meaning Wengyik's, since he's effectively one of the ISODE guys) help. It's a really big barrier to implementation for me. If anyone has a suggestion, I'd love to hear it. 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 ======================================================================== 152 Received: by NERVM (Mailer R2.07) id 5846; Thu, 17 Jan 91 10:02:06 EST Date: Thu, 17 Jan 91 10:02:09 -0500 Reply-To: z3950iw@nervm.nerdc.ufl.edu Sender: "Z39.50 Implementors Workshop" From: yeongw@SPARTACUS.PSI.COM Subject: Interoperable Z39.50 Implementations anyone? X-To: z3950iw@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" On the eve of our upcoming ZIG meeting, I'd like to try to stimulate some interest in implementing Z39.50 as it currently stands. My perception is that there is ever-increasing interest in Information Retrieval systems of various kinds, ranging from simple catalog searching programs to vastly more complex systems capable of the retrieval of multimedia information. If you'll pardon some poetic license (and a lot of melodrama :-)) on my part, the day of the Information Retrieval system is come. Now the question remains as to the vehicle by which information retrieval services may be provided to its would-be users. I see a variety of technologies/approaches vieing to be the basis for information retrieval services, currently. Ignoring for the moment the ftp/telnet (ftam/vt) kludges and the approaches involving electronic mail systems (for brevity; I will be happy to discuss the approaches and why I choose to ignore them in this message privately), there are, in my opinion, three technologies in contention for the role of providing the vehicle to realize information retrieval services. The first is of course Z39.50. The other two are CMIS/CMIP, the OSI Network Management effort, and the OSI Directory (X.500). Basically, I believe that of the three technologies I listed above, Z39.50 has the potential to be the right technology for the task at hand (of being the basis for information retrieval systems/services). Or, to be more accurate, has the potential to be the right way to solve part of the problem anyway: I view the general problem of providing information retrieval services to be a complex one, beyond the capabilities of any single protocol. But more on that some other time ... Given the constituency of this group, I'm probably preaching to the choir here, so I'll not discuss my reasons for preferring Z39.50 over CMIP and X.500. Suffice to say that I believe in Z39.50's potential ability to be part of the solution to the problem of addressing the demand for information retrieval services. However I think that just believing in Z39.50 is not enough anymore. There is a pressing need to deliver solutions, today. It's pretty obvious, at least to me, that nobody can adequately address all the needs of the information user. But I think we can, and should, address the subset that we are capable of, by fielding interoperable Z39.50 implementations. To put it simply, if we don't, others will. There are two key points here: the first is "implementations", the second is "interoperability". Let me address each of them. First of all, I think we need to field implementations because no technology is useful, no matter what it's potential, and no matter how wonderful it is on paper, unless its usable. And of course, for a technology to be usable, it has to be realized in the form of implementations. To put it another way and restate the obvious, standards aren't very useful unless they're implemented. In the context of information retrieval, I guess you could solve the problem by writing on the back of the paper that contains the text defining a proposed information retrieval standard (or in the margins, if your copy of the standard happens to be double-sided :-)). But I think everyone will agree that implementing the standard is more constructive, compared to writing in margins :-). Contributing to my perception that there is a need to field implementations is the reality that it is a lot easier to obtain acceptance for a technology in a vacuum than it is to replace an existing technology with another one, even if the second technology is better. Realistically, there is a certain amount of inertia involved in obtaining acceptance for anything new: witness how many people (like me :-)) have NTSC-compatible TV sets, despite the existence of HDTV standards. It's not that I (and others) don't know that HDTV is superior, it's just that I already have a TV set, and don't want to buy another one :-). Similarly for information retrieval: sometimes, "better" is less important than "first". This is relevant in that even if Z39.50 is "better", that may not matter if a competing technology is "first". With regard to interoperability, I know I'm beginning to sound like a broken record here, but I believe that implementations must not only exist, but must interoperate. That's the whole purpose of having standards. After all, if we weren't interested in interoperating, we could all just go off and devise our own solutions, then go off and implement them. If interoperability wasn't an issue, these solutions would probably be better, if fact, than any standard, in that they would be optimized to our particular hardware/software environments and would thus perform better in those environments than any standard designed to be implemented in any environment. So, finally, I get to the point of this message. I would like to suggest that the ZIG embark on a joint effort to perform interoperable implementations of Z39.50. I'm sure that we have all either performed, or are in the process of performing, Z39.50 implementations. But the problem is that we're all going off into our own little corners and doing the implementations, with no concerted effort to ensure that the implementations will actually work together. I admit that I've been guilty of doing exactly that, for which I am duly chastened :-). But I think the time has come for us to try to do implementations together, based on Z39.50 in its current form. I suspect that part of the problem to date has been that Z39.50 does not contain 'features' that are desirable to some. So we all go off and extend the standard in our own ways to address our own needs, yielding a variety of "Z39.50 plus" implementations. I am certainly sympathetic to the need for additional 'features' in Z39.50: after all I think I can honestly say that I have been its harshest and most vocal critic to date. But while I hope that the standards-keepers will note the need for more 'features' and hopefully rectify those needs in the future, I also believe that we need to do interoperable (that terrible word again :-)) implementations now, based on Z39.50 "as-is". In other words, I'm suggesting that we all put aside our desires for a more feature- and function-rich standard, and make do with the current state of the art. I am only too aware that the current standard cannot provide the functionality desired for many information retrieval systems. But would like to point out two things: first of all, I don't believe that this is an "all or nothing" situation. Nothing says we cannot implement Z39.50 as it is currently specified, and at the same time press the standards-makers for the functionality we desire. Then, as functionality is added to the standard, we can modify our implementations, or reimplement if necessary. But the key here is that there is no reason why we should have to wait until the standard contains *all* the whiz-bang neato functionality we deem necessary before we begin implementing. The second point I'd like to make is that inherent to any standard is compromise. In any given operating environment, a standard solution will always never be as good as a proprietary (in the sense that it is arrived at with no intent of having it work outside of the given environment) solution. The price of suboptimality in any given operating environment has to be paid, in order to gain the advantage of being usable in a variety of environments. Conversely, of course, if the standard doesn't provide the basic functionality necessary, then its a solution to a nonexistent problem :-), and that is also undesirable. So, due to the inherent compromises due to the standard-making process, I think it should be sufficient that a standard be "good enough", as opposed to being "better". The advantage of interoperability is worth the performance price, as long as the standard is at least "good enough". So, to get back to my point, would anyone be interested in discussing a joint effort to implement Z39.50 "as-is"? The implementations will necessarily be prototypes due to Z39.50 being somewhat function-starved right now, but if we limit the scope of the project (in terms of functionality) I think we could come up with something useful. The experience gained would be helpful, and we would be able to actually deliver something useful, albeit on a small scale, today. Needless to say, I have my own ideas about what the joint project should entail with regard to scope and which incarnation of Z39.50 should be the basis. I would be happy to discuss this if there is sufficient interest. Wengyik ======================================================================== 43 Received: by NERVM (Mailer R2.07) id 4220; Thu, 17 Jan 91 06:43:41 EST Date: Wed, 16 Jan 91 14:09:37 EST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Peter Ryall Subject: Re: Re: New Member Questions To: "MARK HINNEBUSCH, FCLA" In-Reply-To: Mail from '"Mark Hinnebusch, FCLA" ' dated Wed, 16 Jan 91 10:52:24 EST Mark - Thank you for your prompt and clear answers to my questions - this helps me catch up with the rest of the group. I didn't make myself very clear in explaining our need for asynchronous posting of result sets, so I will try to explain in more detail - A search does indeed take place in the search/retrieval system to produce each result set, but the mechanism for initiating that search is different than a standard Z39 query. If it were possible , a query would be used to set up the search criteria (target data base attributes, terms, and connectors) and such things as the desired search frequency (e.g, daily, at the time of data base upodate, or as new materials are added to the data base in a continuous/real-time update mode) and the delivery vehicle for result sets. This query would provide the initial scheduling of searches to be initiated at a later time, or on a periodic basis. When these pre-scheduled search times (or events) occurred, the target application would perform the requested search, & return the results to the origin application which sent the query initially. As I think this through, I realize that this type of functionality is most likely outside the scope of Z39.50, & probably requires some type of service provider to submit searches at the appropriate times on behalf of the origin application. The problem this presents in the MDC environment is that the database provider portion of the system is the most knowledgeable about when, where, and how the target data bases are updated with new materials. If you wish to defer this discussion until our meetings, I will be glad to explain it in more detail then, but if there is a simple answer (such as 'no way' or 'over my dead body') I'd like to hear it sooner than later. thanks again... Peter Ryall (MDC) is somewhat of a challenge ======================================================================== 19 Date: Wed, 16 Jan 91 10:52:24 EST From: "Mark Hinnebusch, FCLA" Subject: Re: New Member Questions To: "Z39.50 Implementors Workshop" In-Reply-To: Message of Tue, 15 Jan 91 15:03:34 EST from Re: Peter Ryall's questions - 1. We have agreed in principle on a mechanism to handle proximity searching in the Type 1 query. It is a relatively minor modification to the ASN.1 syntax of the query. We can get into more detail at the meeting. 2. Z39.50 as written does not handle the asynchronous posting of results sets. This would, I believe, be a significant departure. FTAM might be a better solution, since, if I understand your needs, a search does not take place. 3. We are all very interested in alternate media. Z39.50 works quite well with them. There is work to be done in this area in terms of defining attribute and element sets. ======================================================================== 55 Received: by NERVM (Mailer R2.07) id 4266; Tue, 15 Jan 91 15:13:28 EST Date: Tue, 15 Jan 91 15:03:34 EST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Peter Ryall Subject: New Member Questions X-To: Z3950IW@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" I plan to attend the ZIG meeting, although I will most likely have little to contribute, as I only became involved with ZIG a few weeks back. Mead Data Central is very intent on proceeding to implement a published, external interface to our Lexis/Nexis search/retrieval service, & currently plan to use Z39.50 for that interface. I have a few concerns about the versatility of the standard & its ability to meet our needs, but since I am such a newcomer to the ZIG, I don't want to waste a lot of your time covering old familiar ground, or dredging up any long-standing and/or previously-resolved controversies. Please suggest the standard approach for answering such questions, as I don't want to waste anyone's time at the conference, but would like to get up to speed somewhat before-hand. Let me briefly state a couple of my questions, which are basically in the category of requirements I don't see addressed in the standard (of course it could simply be a lack of understanding on my part in some cases). First, we have the need to at least provide the basic features available through our current search interface. Most of these seem to be supported by Z39.50 (in the Type 1 Query), namely all the various terms, attributes, & connectors. However, I also need a mechanism to support the use of proximity connectors, specifically: within 'n' characters/paragraphs, preceeded by/within 'n', & within segment (a segment is a structured document section such as title, author, index, body). A second area that we need to address is that of asynchronous posting of answer sets. We need a mechanism to allow an accessing system to set up search 'filters' (profiles) to search for documents on a periodic basis, or to provide a continuously-updated (or real-time) alert service. As incoming materials are found which meet the criteria of these filters, answer sets will be automatically built, & will need to be delivered to the requesting system through some type of notification/delivery vehicle. It's not obvious to me whether Z39.50 would support this type of 'pre-initialized' asynchronous service. Another area of interest is that of media types other than text; i.e, graphics, tabular numeric data, or highly structured documents such as SGML - is the standard extensible to these media types? Thank you in advance for whatever help you can offer, & I look forward to meeting you all at the conf. Peter Ryall Mead Data Central Dayton, OH (513) 865-7642 ======================================================================== 18 Received: by NERVM (Mailer R2.07) id 3301; Tue, 15 Jan 91 09:41:31 EST Date: Tue, 15 Jan 91 06:42:39 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC Subject: result set question To: "MARK HINNEBUSCH, FCLA" I wish to clarify a technical point in Z39.50, concerning the case when a search executes sucessfully but yields no results, is the result set empty (i.e. contains 0 records) or does it remains unchanged? (this question came up about a month ago, I'm trying to catch up on my mail). Section 3.2.2.1.2 clearly indicates that the result set is empty: "prior to processing the query, the existing result set....will be deleted and a new result set by that name created". This wording was developed specifically to answer this question ======================================================================== 40 Received: by NERVM (Mailer R2.07) id 1193; Mon, 14 Jan 91 16:53:43 EST Date: Mon, 14 Jan 91 13:52:42 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Margaret Baker Subject: meeting info To: "MARK HINNEBUSCH, FCLA" (Speaking for Cliff Lynch, and I hope accurately.) Due to the unexpected demand for rooms and meeting space for the Z3950 implementors' meeting, Clifford has moved the meeting itself into Berkeley, and gotten conference rates at the Shattuck Hotel. The meeting will be all day Thursday 1/31 (beginning at 9 am) and the morning of 2/1 (ending at noon) at the Berkeley Conference Center, 2105 Bancroft Way, Berkeley. This is right across the street from the Shattuck Hotel, and a block from the Berkeley BART station. Breaks will be catered, but not lunch. There are plenty of restaurants nearby. He has reserved a block of rooms at a conference rate at the Shattuck Hotel. The magic word is "Z3950"; the rooms will be held through 1/21. The conference rate is $68 for singles, $78 for doubles. In-state reservations: 800-742-8825; out-of-state reservations: 800-237-5359. FAX: 415-644-2088. Address: Shattuck Avenue and Allston Way, Berkeley. Clifford's earlier comments about "either" the SF or Oakland airports still apply. Berkeley is contiguous to Oakland, across the Bay from SF. Clifford is out of town (which is why I'm posting this), but if you need to talk to someone in his office about the conference arrangements, call Carol Connolly at 415-987-0528. Speaking for myself, see you in 2 weeks. Margaret ======================================================================== 45 Received: by NERVM (Mailer R2.07) id 1151; Mon, 07 Jan 91 15:35:27 EST Date: Mon, 7 Jan 91 15:36:53 EST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Glenn E. Patton" Subject: Re: ??MARC?? X-To: Z3950IW@nervm.nerdc.ufl.edu X-cc: rog@rsch.oclc.org To: "MARK HINNEBUSCH, FCLA" OCLC does not adhere to the ANSI Z39.47 standard because it has not been adopted as the USMARC standard. Since that is the case, we could not adopt Z39.47 because we would then not be creating records that are compatible with USMARC. OCLC *does* adhere to the USMARC character set with one extension. The USMARC character set does not contain a "script l." Since that character was used in pre-AACR2 cataloging as an abbreviation for "leaf" or "leaves," OCLC has, since the very beginning, provided a character (ASCII hex BE) for this character. (Note that the need for the "script l" is a holdover from typewriter days when the saem character was used for the lowercase 'l' and the numeral '1'.) So far as I know, this is the only case in which a non-USMARC character would appear in bibliographic data communicated in an OCLC-MARC record (whether that record appears on tape or is transmitted electronically using the "export" function in OCLC's PRISM Service). For tape records only, there is the possibility of a non-USMARC character in Leader/22. OCLC has "misused" that byte of the leader for years to contain a "transaction" code that reflects what kind of online transaction generated the tape record. Some of the codes are ASCII characters which are not defined in the USMARC character set -- in addition to the fact that we shouldn't be used that leader byte anyway. We're trying to find a better location for this data but have not yet found one so at present we can only acknowledge our sin. Only the "script l" is likely ever to appear in a record that would be sent out in a Z39.50-based search implementation. a Glenn Patton Internet: gep@rsch.oclc.org Online Computer Library Center 6565 Frantz Rd, Dublin OH 43017 Phone: (614) 764-6371 ======================================================================== 27 Received: by NERVM (Mailer R2.07) id 0676; Mon, 07 Jan 91 15:13:15 EST Date: Mon, 7 Jan 91 14:09:01 CST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Sean Donelan Subject: RE: protocol version X-To: Z3950IW@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" > > You should include all the protocol versions you are willing and > able to use for this instance of communication. The higest > numbered version common to both the origin and target will be the > one selected. I think Randy's question was more "Is what we're calling Version 2 of the standard, really version 2?" Or is it Version 1 of ISO merged into NISO version 2? Or what? We can set or not set any bit, what are other folks expecting from an implementation based on the "DRAFT" changes passed out at the previous meeting. [Its the simple things that confuse you the most...] -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO 63132-1806 Domain: sean@dranet.dra.com, Voice: (Work) +1 314-432-1100 ======================================================================== 6 Date: Mon, 07 Jan 91 15:02:58 EST From: "Mark Hinnebusch, FCLA" Subject: version To: "Z39.50 Discussion List" To be specific, we have agreed to write to version 2 of the standard. ======================================================================== 18 Received: by NERVM (Mailer R2.07) id 0881; Mon, 07 Jan 91 15:20:32 EST Date: Mon, 7 Jan 91 10:37:54 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Wayne Davison Subject: Re: ??MARC?? To: "MARK HINNEBUSCH, FCLA" REPLY TO 01/04/91 14:15 FROM Z3950IW@NERVM.BITNET "Z39.50 Implementors Workshop": Re: ??MARC?? We do not know of any system that has implemented Z39.47 (ANSEL). I agree that they only way to make the character set situation better is to get involved. We certainly spend a lot of staff time and effort in this area. To: Z3950IW@NERVM.BITNET ======================================================================== 17 Received: by NERVM (Mailer R2.07) id 0076; Mon, 07 Jan 91 14:57:00 EST Date: Mon, 7 Jan 91 09:50:14 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Wayne Davison Subject: protocol version To: "MARK HINNEBUSCH, FCLA" REPLY TO 01/07/91 09:26 FROM Z3950IW@NERVM.BITNET "Z39.50 Implementors Workshop": protocol version You should include all the protocol versions you are willing and able to use for this instance of communication. The higest numbered version common to both the origin and target will be the one selected. To: Z3950IW@NERVM.BITNET ======================================================================== 11 Received: by NERVM (Mailer R2.07) id 8542; Mon, 07 Jan 91 12:22:52 EST Date: Mon, 7 Jan 91 11:22:55 CST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: RANDY@DRANET.DRA.COM Subject: protocol version X-To: z3950iw@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" Could somebody tell me what protocol version(s) should be used in an Initialize Request? ======================================================================== 36 Received: by NERVM (Mailer R2.07) id 3618; Mon, 07 Jan 91 22:42:15 EST Date: Mon, 7 Jan 91 09:06:02 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch Subject: mtg info To: "MARK HINNEBUSCH, FCLA" On the implementor's group meeting, it will indeed by 9 am Thurs 31 Jan through noonish 1 Feb. We had originally hoped to hold it in conference space in Berkeley but it now seems like it will be more practical to hold it at the DLA Offices in Oakland. I will post the conference room number in a bit. A few possibly useful bits of information. There is parking at the Kaiser center; it is not cheap (about $12/day). Kaiser is a 2 block walk to BART. I have never heard of any of the hotels that Mark H. mentions. My suggestions would be to try either the Oakland Hyatt (1 BART stop or a few-block walk to Kaiser) or the Shattuck Hotel in Berkeley (a couple BART stops away, but puts most of Berkeley in easy reach for evening activities). I will check out rates and things, and post this info plus other hotel suggestions if I can come up with any. A few other pointers. Taxi from the airport is fairly expensive; there are shuttle bus services and I can provide info on these. You may want to fly either into Oakland or into San Fransisco; Oakland is a bit closer but not that much, so either airport is feasible. SFO has a much wider choice of flights. For those driving, there is a map and a set of directions that I can have faxed out. More info to follow. Clifford ======================================================================== 28 Date: Mon, 07 Jan 91 10:50:17 EST From: "Mark Hinnebusch, FCLA" Subject: Z39.50 IG meeting To: "Z39.50 Discussion List" The ZIG meeting will be held at DLA headquarters: University of California Division of Library Automation Kaiser Center, 8th Floor 300 Lakeside Drive Oakland Ca 94612-3550 Voice: 415-987-0522 FAX: 415-839-3573 from 9AM Thursday January 31 through noon Friday, February 1st, 1991. I have identified three possible hotels. I HAVE NO INFORMATION ABOUT THEM EXCEPT THEIR LOCATION APPEARS TO BE CLOSE TO DLA. I hope that Cliff or Mark can make their own recommendations. Also, I chose the cheapest I could find since Florida is in a budget crunch. The hotels are: Apple Inn (800) 323-8622 ($58) Jack London Inn (415) 444-2032 ($38) Washington Hotel (415) 452-1776 ($60) Mark, Cliff, are any of these OK or are they roach motels? ======================================================================== 40 Received: by NERVM (Mailer R2.07) id 4021; Fri, 04 Jan 91 19:54:28 EST Date: Fri, 4 Jan 91 16:08:00 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "SYLVIA CARSON (814) 865-1818" Subject: Re: ??MARC?? To: "MARK HINNEBUSCH, FCLA" To follow up on Mark's last paragraph re multiple formats for different types of bibliograhic data ... there are currently seven formats defined in USMARC -- Books, Archives & Manuscripts, Computer Files, Maps, Music, Visual Materials (Films), and Serials. Character positions 6 and 7 in the Leader identify the format. Mark mentioned that you need to know which format is being used since a particular tag may have different content in different formats. The INTENT of a field is the same across all formats in which it applies, but, for example, in one format all subfields defined for that field may be valid, while in another format only selected subfields may be valid. Knowing what format you've got lets you check for the validity of data elements in that format. The possiblility of having an "integrated" USMARC bibliographic format has been discussed with in the library community during the last several years. Format integration would validate data elements for ALL forms of material, and remove the restricions on data elements that make them valid only for specific forms of material. The result would be a single bibliographic format containing data elements that can be used to describe many forms of material ... a data dictionary rather than a set of diverse formats with validation characteristics relating to specific library cataloging practices. The decisions regarding what will be retained, added and/or deleted from the existing formats to create an integrated USMARC format have already been made, and plans are in the works for implementation of "format integration" over the next few years. Format integration should simplify things on both the system and library-use sides. Yes, there is a USMARC, an OLCL MARC, and an RLIN MARC. There are also local versions; for example, we have "LIAS MARC". For mapping purposes, most issues are taken care of by special handling the X9X and 9XX fields. ======================================================================== 27 Received: by NERVM (Mailer R2.07) id 2546; Fri, 04 Jan 91 17:09:38 EST Date: Fri, 4 Jan 91 13:33:38 EST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Howard Pasternack Subject: Re: ??MARC?? To: "MARK HINNEBUSCH, FCLA" In-Reply-To: Message of Fri, 4 Jan 91 09:14:23 EST from Another interesting variation in MARC occurs in the character sets used by the various services. There is an ANSI standard for the "Extended Latin Alphabet Coded Character Set for Bibliographic Use" (Z39.47-1985) and a character set defined in "USMARC Specifications for Record Structure, Character Sets, Tapes" (LC Cataloging Distribution Service, 1990). The two "standards" are not the same. Neither OCLC nor RLIN adheres to the USMARC standard. I am not sure whether OCLC adheres to ANSI, but I know that RLIN does not. >>flame on The situation with the character sets is a disgrace. Librarians who bemoan the lack of standard software to support the display of the characters have only themselves to blame. >>flame off Howard Pasternack Brown University ======================================================================== 29 Received: by NERVM (Mailer R2.07) id 2347; Fri, 04 Jan 91 17:00:24 EST Date: Fri, 4 Jan 91 10:20:18 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Lennie Stovel Subject: ??MARC?? To: "MARK HINNEBUSCH, FCLA" REPLY TO 01/04/91 10:01 FROM Z3950IW@NERVM.BITNET "Z39.50 Implementors Workshop": ??MARC?? Wengyik, The document you need is called "USMARC Format for Bibliographic Data", published by the Library of Congress Network Development and MARC Standards Office (yes, where Ray works) and available through the Library of Congress Cataloging Distribution Service. It combines the definitions for books, serials, etc., that Mark H. referred to. In the future these various formats will be integrated so that all tags are valid for all formats. After you've absorbed USMARC, if you are interested in the RLIN MARC variations, let me know and I will send you a copy of "The RLIN MARC Format". -- Lennie To: Z3950IW@NERVM.BITNET ======================================================================== 43 Date: Fri, 04 Jan 91 09:14:23 EST From: "Mark Hinnebusch, FCLA" Subject: Re: ??MARC?? To: "Z39.50 Implementors Workshop" In-Reply-To: Message of Fri, 4 Jan 91 08:00:30 -0500 from Wengyik: You got it right. The architecture that all MARC records use and which is incorrectly but almost universally referred to when people talk about "MARC" records is actually NISO Z39.2. This defines a record architecture consisting of a fixed length leader followed by a directory of fields followed by variable length fields. It also defines the content and format of the leader and directory but says nothing about the contents of the fields. The field architecture was originally defined by the Library of Congress, in fact in the office that Ray works, although it had a different name then. All "MARC" records share the convention of having "fixed" fields with referrents in the range 001 through 009 and "variable" fields with referrents 010 to 999. The referrents, called tags, reside in the directory along with offsets and lengths. Variable fields consist of two bytes called "indicators" that always exist and a variable number of "subfields" delimited by a special character followed by a single byte subfield identifier. Subfields may or may not exist, may repeat, may be of any length. Fields may or may not exist, may repeat, may be of any length. The MARC standard, promulgated by and available from Library of Congress, defines the content and format of the fields and subfields, specifies which are required and which may repeat. They have a convention of reserving ranges of tags, usually with nines in them, for local data. OCLC, RLG, FCLA and many others, have defined their own tags, usually following the nines convention. This has lead to the "multiple MARC" condition. However, a well-structured program doesn't need to know very much, if anything, about the variations. By the way, there are different content designations for bibliographic data describing different types of objects. There is a format for books, one for serials, one for maps and globes, one for music, one for machine readable data, on for archives, manuscripts and appearently museums, and probably some I missed. There is also one to describe holdings of materials, called MFHL, the MARC Format for Holdings and Locations. How you tell which is in the leader. Your program must know about the different types since a particular tag may have different content in different formats. ======================================================================== 32 Received: by NERVM (Mailer R2.07) id 8701; Fri, 04 Jan 91 07:59:45 EST Date: Fri, 4 Jan 91 08:00:30 -0500 Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: yeongw@SPARTACUS.PSI.COM Subject: ??MARC?? X-To: z3950iw@nervm.nerdc.ufl.edu X-cc: yeongw@psi.com To: "MARK HINNEBUSCH, FCLA" [No, this is not yet another tirade about MARC on my part :-) :-)] I've been doing some reading lately, and getting the impression that MARC is not one standard, but a family of standards. I know that there are variations among the various national MARC standards. For example USMARC and UKMARC differ in some ways. However is it also true that there are several different versions of the MARC standard in use within the United States? For example, when OCLC and RLG provide records in "MARC format", are the records identical? Please note that I'm not trying to pick on anyone here: OCLC and RLG were the first two organizations I could think of off the top of my head. If it is the case that there are variations in what is called "MARC" in use among different organizations, is there some definitive document that describes the record format "USMARC"? Where can I obtain such a document, if it exists? Thanks. Wengyik ======================================================================== 42 Received: by NERVM (Mailer R2.07) id 5619; Thu, 03 Jan 91 10:20:58 EST Date: Thu, 3 Jan 91 10:22:12 EST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ralph LeVan Subject: Re: Question About Init X-To: Z3950IW@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" > In working on our implementation of Z30.50 we have come up with the following > question: Is it possible for a target to tell that an incoming ADPU has > already sent an init request and if so which init request. We are concerned > about identifying a way to determine this at the application level. Perhaps > we have missed something along the way. Thanks for your help. Let me try this one. If I understand the question right, you want to know if the target can distinguish between users, based solely on information passed at the application layer. (I think the underlying assumption here is that you are not building z39.50 on top of some stack. That was how I tried to build it initially also, until I got straightened out.) The answer is that you can't. There is information necessary outside of the z39.50 standard. The "standard" solution is to build z39.50 on top of an OSI stack and then there would be a mechanism to query the session layer to identify which session to associate a message with. If you're implementing z39.50 without an OSI stack, you're going to need to emulate some of the session layer services. The easiest way to do this is to put a fixed length header on your BER records that contains a session id and a message-type indicator (connect, disconnect and data perhaps). Then, as an Init shows up, hopefully with no session id and a connect indication, you can assign a session id that would necessarily be present on any future messages from the same source. I hope this had something to do with your question. 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 ======================================================================== 13 Date: Thu, 03 Jan 91 09:03:23 EST From: "Mark Hinnebusch, FCLA" Subject: re: question about INIT To: "Z39.50 Discussion List" Speaking only for the IBM OSI/CS environment, you issue a LISTEN. When an a-associate comes in, you are given, by the OSI/CS, a unique association ID which you then use as a handle for the association. In this environment, you would index your state tables with the associationID to ascertain the current state of the association. I can't really see how any other OSI support package could do it any other way. --mark h ======================================================================== 32 Received: by NERVM (Mailer R2.07) id 3736; Wed, 02 Jan 91 19:30:06 EST Date: Wed, 2 Jan 91 19:31:24 -0500 Reply-To: yeongw@psi.com Sender: "Z39.50 Implementors Workshop" From: yeongw@SPARTACUS.PSI.COM Subject: Re: Question About Init X-To: "Z39.50 Implementors Workshop" To: "MARK HINNEBUSCH, FCLA" In-Reply-To: Your message of Wed, 02 Jan 91 17:08:00 -0500. <9101022312.AA19871@psi.com> > In working on our implementation of Z30.50 we have come up with the following > question: Is it possible for a target to tell that an incoming ADPU has > already sent an init request and if so which init request. We are concerned > about identifying a way to determine this at the application level. Perhaps > we have missed something along the way. Thanks for your help. > This assumes something about your implementation, but wouldn't the target know by virtue of the state information being kept on the Z39.50 session? I would imagine that some state information, like the message size limits and the options bitstring (among other things, this is off the top of my head) for example, would need to be kept by a target for each Z39.50 session. Also, some sort of state variable would need to be kept for each session for the target IRPM. Well, maybe not a variable per se, but some indication of IRPM state. If this is true, then whether or not an Init has been sent 'falls out' of the state information. Is this not correct? Am I missing something also? Wengyik ======================================================================== 16 Received: by NERVM (Mailer R2.07) id 3282; Wed, 02 Jan 91 18:09:43 EST Date: Wed, 2 Jan 91 17:08:00 CDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: RANDALL@NUACC.BITNET Subject: Question About Init To: "MARK HINNEBUSCH, FCLA" In working on our implementation of Z30.50 we have come up with the following question: Is it possible for a target to tell that an incoming ADPU has already sent an init request and if so which init request. We are concerned about identifying a way to determine this at the application level. Perhaps we have missed something along the way. Thanks for your help. Sara Randall NOTIS Systems, Inc.