======================================================================== 34 Received: by NERVM (Mailer R2.07) id 6636; Thu, 20 Dec 90 15:12:08 EST Date: Thu, 20 Dec 90 12:08:43 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC To: "MARK HINNEBUSCH, FCLA" I have clarification from ANSI on the structure of object ids to be registered nationally. The oid for Z39.50 will be "1.2.840.x", where x is yet to be assigned. (1=ISO, 2=member body, 840=U.S.; there is no separate level for "standard", as previously expected. Instead, a range of numbers at the fourth level is allocated for standards. Therefore, the previously projected id with "100" in it was wrong. The "3" component was also wrong.) I will probably have the assigned value of "x" by the first of the year (and I will be out until then). This structure is still not official until I get it in writing (along with "x"), but I believe it to be reliable, since I got it straight from ANSI headquarters over the phone, and the registration procedures are now finalized. The fifth level will parallel the ISO object identifiers for SR (at least those defined so far): 1 = application context, 2 = abstract syntax, 3 = attribute set id, 4 = diagnostic set id. Thus I cannot yet assign exact oids for the basic appliciation context and abstract syntax analogous to sr-A-context and sr- syntax. However, they will both be assigned relative value 1. I.e. the basic Z39.50 application context will be "1.2.840.x.1.1" and the basic Z39.50 abstract syntax will be "1.2.840.x.2.1". I hope (Wengyik) that this is sufficient for the time being. ======================================================================== 30 Received: by NERVM (Mailer R2.07) id 6902; Thu, 20 Dec 90 15:29:33 EST Date: Thu, 20 Dec 90 10:05:45 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Wayne Davison Subject: OIDs X-To: z3950iw@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" REPLY TO 12/19/90 10:34 FROM Z3950IW@NERVM.NERDC.UFL.EDU: OIDs Wengyik - #1 It is not clear to me how you are using the term "object descriptors". Are you thinking in terms of the formal defintion in ISO 8824, Clause 35? If so, I would need further information about what ANSI and NISO are doing with the assignment of object descriptors as part of the registration process before I could verify my answer. I will copy Ray on this. #2 I think that the second element of your official object id for both the attribute-set and diagnostic-set should be 2 rather than three. As I read ISO 8824, Annex B, Clause, 2 is the value for the member-body arc and 3 is the value for the identified- organization arc. The USA goes under the member-body arc. Under the member-body arc, 842 is the correct value for the USA arc, as per ISO 3166: 1988, pg 772. To: Z3950IW@NERVM.NERDC.UFL.EDU cc: BB.RAY ======================================================================== 21 Received: by NERVM (Mailer R2.07) id 8692; Wed, 19 Dec 90 13:31:28 EST Date: Wed, 19 Dec 90 13:38:00 -0500 Reply-To: z3950iw@nervm.nerdc.ufl.edu Sender: "Z39.50 Implementors Workshop" From: yeongw@SPARTACUS.PSI.COM Subject: Application context and syntax definitions X-To: bb.ray%rlg@nervm.nerdc.ufl.edu X-cc: z3950iw@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" Mr. Denenberg, Could you please assign oids to represent the Z39.50 application context and application syntax (similar to "sr-A-context" and "sr-syntax" in 10163)? I've reached a point in my Z39.50 implementation where I need them. Thanks. Wengyik ======================================================================== 32 Received: by NERVM (Mailer R2.07) id 8593; Wed, 19 Dec 90 13:31:00 EST Date: Wed, 19 Dec 90 13:36:47 -0500 Reply-To: z3950iw@nervm.nerdc.ufl.edu Sender: "Z39.50 Implementors Workshop" From: yeongw@SPARTACUS.PSI.COM Subject: OIDs X-To: z3950iw@nervm.nerdc.ufl.edu X-cc: yeongw@psi.com To: "MARK HINNEBUSCH, FCLA" Would I be correct in assuming that the object descriptors "niso standard Z39.50" map right onto the object identifier prefixes from ISODE, and which LC is going to obtain from ANSI? That is, for example, that niso standard Z39.50 attribute-set (3) bib-1 (1) is: 1.17.4.3.40.3.1 (ISODE) 1.3.840.100.x.3.1 (OFFICIAL) and niso standard z39.50 diagnostic-set (4) bib-1 (1) is: 1.17.4.3.40.4.1 (ISODE) 1.3.840.100.x.4.1 (OFFICIAL) Thanks. Wengyik ======================================================================== 16 Received: by NERVM (Mailer R2.07) id 7072; Wed, 12 Dec 90 12:42:18 EST Date: Wed, 12 Dec 90 09:42:46 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Wayne Davison Subject: oids for Z39.50 To: "MARK HINNEBUSCH, FCLA" REPLY TO 12/11/90 12:39 FROM Z3950IW@NERVM.BITNET "Z39.50 Implementors Workshop": oids for Z39.50 I understand that ANSI is now also registering organizations. The charge is $1,000. Ms. Beth Somerville is in charge of registration authority procedures at ANSI. To: Z3950IW@NERVM.BITNET ======================================================================== 19 Received: by NERVM (Mailer R2.07) id 0867; Tue, 11 Dec 90 15:36:40 EST Date: Tue, 11 Dec 90 12:37:19 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC Subject: oids for Z39.50 To: "MARK HINNEBUSCH, FCLA" I have an (informal) agreement with ANSI to obtain an object identifier for Z39.50 reasonably soon, as well as authority to register subordinate oids. I think (but am not entirely certain yet) that the oid will be 1.3.840.100.x where x is the number yet to be assigned for Z39.50 (1=ISO, 3=member body, 840=ANSI, 100=standard). In any case, I'll get this clarified. The reason this is taking so long is that the procedures for national registration, which have been under development for about two years, are finally (i.e. this week) reasonably well-settled, to the extent that ANSI is now willing to assign a permanent id, in dadvance of final refinement of the procedures. ======================================================================== 12 Received: by NERVM (Mailer R2.07) id 8236; Tue, 11 Dec 90 08:58:14 EST Date: Tue, 11 Dec 90 05:59:25 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC Subject: Response to Wengyik's question To: "MARK HINNEBUSCH, FCLA" In response to Wengyik's question "Would LC care to administer it in their capacity as Z39.50 Maintenance Organization?"; LC, as Z39.50 maintenance agency, will be happy to administer registration of all Z39.50 objects. ======================================================================== 23 Received: by NERVM (Mailer R2.07) id 6047; Mon, 10 Dec 90 18:54:52 EST Date: Mon, 10 Dec 90 18:51:56 -0500 Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: yeongw@SPARTACUS.PSI.COM Subject: ISODE oid assignment X-To: z3950iw@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" 1.17.4.3.40 has been assigned to us. Note that this assignment is *unofficial* by dint of the 1.17 subtree itself being unofficial. Hence when Ray gets an official assignment from the appropriate people, this assignment is superseded. In the interests of getting something to work with now however, I'd suggest we use the assignment in the interim. Would LC care to administer it in their capacity as Z39.50 Maintenance Organization? That way, since they'll presumably be administering the official assignment, there is no change of administrations moving from one oid to another. Wengyik ======================================================================== 11 Received: by NERVM (Mailer R2.07) id 2043; Mon, 10 Dec 90 09:42:21 EST Date: Mon, 10 Dec 90 06:43:00 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC Subject: Registration of Z39.50 objects To: "MARK HINNEBUSCH, FCLA" In response to the recent discussion on registration of Z39.50 objects, I am working on obtaining a node for LC/NISO on the U.S. registration tree. I'll have more on this soon. ======================================================================== 15 Received: by NERVM (Mailer R2.07) id 0262; Fri, 07 Dec 90 19:49:19 EST Date: Fri, 7 Dec 90 19:46:39 -0500 Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: yeongw@SPARTACUS.PSI.COM Subject: Request for oid subtree X-To: bug-isode@cheetah.ca.psi.com X-cc: z3950iw@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" I'd like to request that a subtree of the (unofficial :-)) ISODE subtree be assigned to the Z39.50 Implementor's Group for the purpose of Z39.50 development. Thanks. Wengyik ======================================================================== 71 Received: by NERVM (Mailer R2.07) id 9390; Fri, 07 Dec 90 17:07:06 EST Date: Fri, 7 Dec 90 17:05:33 -0500 Reply-To: z3950iw@nervm.nerdc.ufl.edu Sender: "Z39.50 Implementors Workshop" From: yeongw@SPARTACUS.PSI.COM Subject: Re: Linking abstract syntaxes to specific databases X-To: Z3950IW@nervm.nerdc.ufl.edu X-cc: yeongw@psi.com To: "MARK HINNEBUSCH, FCLA" In-Reply-To: Your message of Fri, 07 Dec 90 11:26:54 -0800. <9012071924.AA21872@psi.com> > > But now, what happens if syntax X is negotiated for records > > in database A, and syntax Y is negotiated for records in > > database B, then an origin sends a request for records that > > originated from database B requesting a syntax of X? > > I guess that if the target can provide records from database B in > syntax X it will do so, otherwise it will supply them in syntax Y. > > The process of negotiating Presentation Contexts for syntax X and > syntax Y does not touch on the matter of the relationship of the > abstract syntaxes to any particular database. As long at the > target makes sure that a presentation context has been established > for its default abstract syntax for each database then communication > should be able to proceed. Unless we elect to use the Presentation > Context Definition Functional Unit, this means that the origin> and > target must agree on a default abstract syntax for each and EVERY > database that the origin will search during the entire association. > This is not very flexible, and assumes a lot of a priori knowledge > (at least on the part of the origin). This deserves some more > discussion. In the short term, I'd like to suggest that we just add another diagnostic "record syntax not supported for retrieval", or something similiar. In the long term, I'd suggest that the larger problem of discovery within Z39.50 be addressed. I look at the record syntax problem not as one of how to associate additional context (the database) with a syntax during negotiation, but a simpler (from my point of view) problem of how the origin is to discover what syntaxes records from a particular database can be transferred in. I continue to contend that record syntaxes aren't really a subject for negotiation: for any given database, a target will support some set of syntaxes for record transfer. If the syntax requested by an origin is a member of that set, then records can be returned. Otherwise records can't be returned. No amount of negotiation is going to render a target capable of supporting a new syntax, and I don't think a target really cares what syntax an origin wants records in, as long as it is a syntax that it supports (this is an assumption. Is this true?). Sort of like "cars are available in any color as long as it's black" :-). So the problem just becomes one of the origin discovering the membership of the legal record syntax set, for each database that the origin cares to search. Which brings us back to one of my favorite subjects, Explain :-) :-). If we provide Z39.50 with a discovery mechanism, we not only solve the record syntax problem (assuming you accept my phrasing of the problem above), but also the problems of discovering all the other little items of 'infrastructure' that I, at least, think need discovering. But that's in the long term. As Mr. Davison points out, this needs further, significant, discussion. In the short term, I propose we just add "unknown/illegal" type diagnostics for all the discovery type problems. This solves the problems, albeit in a trivial, and not very useful way. Wengyik ======================================================================== 29 Received: by NERVM (Mailer R2.07) id 8718; Fri, 07 Dec 90 15:04:57 EST Date: Fri, 7 Dec 90 12:04:02 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "John A. Kunze" Subject: Preferred record syntax, registration trees, and application-context To: "MARK HINNEBUSCH, FCLA" In-Reply-To: "John A. Kunze"'s message of Fri, 7 Dec 90 11:40:09 PST <9012071952.AA22631@lilac.berkeley.edu> Date: Fri, 7 Dec 90 11:40:09 PST From: "John A. Kunze" Date: Fri, 7 Dec 90 08:32:07 -0500 From: yeongw@SPARTACUS.PSI.COM But now, what happens if syntax X is negotiated for records in database A, and syntax Y is negotiated for records in database B, then an origin sends a request for records that originated from database B requesting a syntax of X? I don't think that can happen. Presentation syntax is negotiated on a per association basis, not per database. On second thought, I think I just confused presentation transfer syntax with record syntax. Oops. -John ======================================================================== 24 Received: by NERVM (Mailer R2.07) id 8447; Fri, 07 Dec 90 14:43:05 EST Date: Fri, 7 Dec 90 11:40:09 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "John A. Kunze" Subject: Preferred record syntax, registration trees, and application-context X-cc: SSTONE@violet.Berkeley.EDU To: "MARK HINNEBUSCH, FCLA" In-Reply-To: yeongw@SPARTACUS.PSI.COM's message of Fri, 7 Dec 90 08:32:07 -0500 <9012071339.AA13271@lilac.berkeley.edu> Date: Fri, 7 Dec 90 08:32:07 -0500 From: yeongw@SPARTACUS.PSI.COM But now, what happens if syntax X is negotiated for records in database A, and syntax Y is negotiated for records in database B, then an origin sends a request for records that originated from database B requesting a syntax of X? I don't think that can happen. Presentation syntax is negotiated on a per association basis, not per database. -John ======================================================================== 40 Received: by NERVM (Mailer R2.07) id 8223; Fri, 07 Dec 90 14:25:43 EST Date: Fri, 7 Dec 90 11:26:54 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Wayne Davison Subject: Linking abstract syntaxes to specific databases To: "MARK HINNEBUSCH, FCLA" REPLY TO 12/07/90 05:36 FROM YEONGW@PSI.COM: Linking abstract syntaxes to specific databases Wengyik - We seem to have discovered something else under the latest rock that you turned over. > But now, what happens if syntax X is negotiated for records > in database A, and syntax Y is negotiated for records in > database B, then an origin sends a request for records that > originated from database B requesting a syntax of X? I guess that if the target can provide records from database B in syntax X it will do so, otherwise it will supply them in syntax Y. The process of negotiating Presentation Contexts for syntax X and syntax Y does not touch on the matter of the relationship of the abstract syntaxes to any particular database. As long at the target makes sure that a presentation context has been established for its default abstract syntax for each database then communication should be able to proceed. Unless we elect to use the Presentation Context Definition Functional Unit, this means that the origin and target must agree on a default abstract syntax for each and EVERY database that the origin will search during the entire association. This is not very flexible, and assumes a lot of a priori knowledge (at least on the part of the origin). This deserves some more discussion. To: YEONGW@PSI.COM cc: Z3950IW@NERVM ======================================================================== 45 Received: by NERVM (Mailer R2.07) id 7203; Fri, 07 Dec 90 12:22:51 EST Date: Fri, 7 Dec 90 12:22:35 EST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark H. Kibbey" Subject: sirsi To: "MARK HINNEBUSCH, FCLA" This is all I found in our datafiles for the last two years. - Mark IDNUM 06319156 TYPE product announcement DATE 880322 AUTHOR Young, Jacky TITLE The Unicorn Collection Management System: its structure and features. (includes related articles on advantages of Unicorn's distributive intelligence structure and an installation case study of Unicorn) (product announcement) SYSTEM UNIX XENIX SOURCE Library Hi Tech v6 n1 p61(7) 1988 Spr SUBJECT Libraries Automation Information Management Integrated Systems New Product Sirsi Corp.--product introduction Unicorn Collection Management System (computer program)--usage GRAPHICS chart program CAPTIONS System profile. Unicorn overdue notice structure. SICCODES 7372 8230 8231 ABSTRACT The Unicorn Collection Management System, developed by Sirsi Corp, is an integrated library automation system. Some of the modules include: bibliographic and inventory control; circulation; enhanced public access with searching techniques; academic reserves; acquisitions; serials control; authority control; materials booking; and electronic mail. Records are stored and displayed either in a short form, full-MARC, or library-designed format. On-line and off-line interfaces are available to bibliographic services such as OCLC. Unicorn is written in C, available for UNIX or XENIX operating systems, and can be bought as software only or as a turnkey system. ======================================================================== 44 Received: by NERVM (Mailer R2.07) id 4914; Fri, 07 Dec 90 08:33:46 EST Date: Fri, 7 Dec 90 08:32:07 -0500 Reply-To: yeongw@psi.com Sender: "Z39.50 Implementors Workshop" From: yeongw@SPARTACUS.PSI.COM Subject: Re: Preferred record syntax, registration trees, and application-context X-To: z3950iw@nervm.nerdc.ufl.edu X-cc: yeongw@psi.com To: "MARK HINNEBUSCH, FCLA" In-Reply-To: Your message of Thu, 06 Dec 90 16:23:34 -0800. <9012070026.AA13022@psi.com> > A) Record syntaxes ARE subjects of presentation negotiation because > the Presentation layer must negotiate a transfer syntax for them. Got it, finally. This makes sense to me now. Thanks for the explanation. But now, what happens if syntax X is negotiated for records in database A, and syntax Y is negotiated for records in database B, then an origin sends a request for records that originated from database B requesting a syntax of X? > B) The ISODE tree might well serve as an interim registration > mechanism for us. We might also check with LC to see if they have > anything from NIST. I'll send off a request for a tree to be assigned to the ZIG later today, unless LC speaks up either with a tree from the NIST or someone volunteers to do it. I don't think this group can (or should) speak for 'niso' or the Z39.50 standards body itself, so it doesn't seem appropriate to ask for a tree identified with either the 'niso' or 'z39' object descriptors. > D) I tend to think of Z39.50 version 2 as a superset of ISO 10163, > so if we implement Z39.50 version 2 we will also be implementing ISO > 10163. Actually the question was intended to establish whether we were implementing to the draft of Z39.50 Version 2 that was distributed at the last ZIG meeting, or to SR + U.S. Ballot comments. I guess the 'draft of' was implicit. Sorry for the bad terminology. Wengyik ======================================================================== 55 Received: by NERVM (Mailer R2.07) id 2313; Thu, 06 Dec 90 19:22:56 EST Date: Thu, 6 Dec 90 16:23:08 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Wayne Davison Subject: Preferred record syntax, registration trees, and application-context To: "MARK HINNEBUSCH, FCLA" REPLY TO 12/05/90 06:14 FROM YEONGW@PSI.COM: Preferred record syntax, registration trees, and application-context Wengyik - A) Record syntaxes ARE subjects of presentation negotiation because the Presentation layer must negotiate a transfer syntax for them. The point is that for any information (any APCI and any User Information) to be exchanged between Application-Entities, the Presentation Layer must have first paired a transfer syntax with the abstract syntax for that information. Each pair is a separate Presentation Context. The fact that the Application Layer uses Presentation Layer services to exchange the oids for abstract syntaxes may seem an architectural oddity. B) The ISODE tree might well serve as an interim registration mechanism for us. We might also check with LC to see if they have anything from NIST. C) We need an application-context-definition, and id, for an application context that contains ACSE and Z39.50 version 2. The ACSE protocol standard does not itself contain any application-context-definitions. During application-association establishment, the ACSE does exchange APCI containing the oid for the application-context for that association. There is always exactly one application-context per application association. In terms of formal logic, the application-context is the conceptual schema for the universe of discourse for that association. In other words, the application-context contains all of the rules governing the actions of both parties. An application-context always contains all of the application-service-elements (ACSE and Z39.50 in this case) that will be used during the association. Many of these rules are 'contained' by referencing protocol standards and profiles. D) I tend to think of Z39.50 version 2 as a superset of ISO 10163, so if we implement Z39.50 version 2 we will also be implementing ISO 10163. To: YEONGW@PSI.COM cc: Z3950IW@NERVM.BITNET ======================================================================== 18 Date: Thu, 06 Dec 90 16:16:48 EST From: "Mark Hinnebusch, FCLA" Subject: Length restrictions in ASN.1 To: "Z39.50 Discussion List" Good to know we all agree that length restrictions do not belong in the standard. I just thought of an alternative to diagnostics. If I guarantee that my implementation will be able to handle any "atomic" component of a PDU no larger than a particular size, then using that size as my PreferredMessageSize and ABORTing if it is not agreed to, I can guarantee that the well-behaved partner is not going to violate my length restrictions. However, this is a somewhat draconian measure. The disadvantage is that it could, in some implementations, lead to unnaturally small PreferredMessageSize values. The advantage is that it obviates the need for length error diagnostics. Just to sweeten the pot... :-) ======================================================================== 15 Received: by NERVM (Mailer R2.07) id 0417; Thu, 06 Dec 90 15:36:03 EST Date: Thu, 6 Dec 90 12:33:34 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Wayne Davison Subject: Re: Length restrictions in ASN.1 To: "MARK HINNEBUSCH, FCLA" REPLY TO 12/06/90 11:35 FROM Z3950IW@NERVM.BITNET "Z39.50 Implementors Workshop": Re: Length restrictions in ASN.1 I cast my vote for NOT including length restrictions in the standard. To: Z3950IW@NERVM.BITNET ======================================================================== 15 Received: by NERVM (Mailer R2.07) id 0323; Thu, 06 Dec 90 15:35:33 EST Date: Thu, 6 Dec 90 12:32:42 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Wayne Davison Subject: Re: Length restrictions in ASN.1 To: "MARK HINNEBUSCH, FCLA" REPLY TO 12/06/90 11:39 FROM YEONGW@PSI.COM: Re: Length restrictions in ASN.1 I agree with Wengyik that length limitations should NOT be part of the standard. To: YEONGW@PSI.COM cc: Z3950IW@NERVM.BITNET ======================================================================== 19 Received: by NERVM (Mailer R2.07) id 9697; Thu, 06 Dec 90 14:32:22 EST Date: Thu, 6 Dec 90 14:30:32 EST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ralph LeVan Subject: Re: Length restrictions in ASN.1 X-To: Z3950IW@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" Mark, I agree that size restrictions are locally imposed and should not be part of the standard. You have my blessings in your pursuit of appropriate responses to those who would exceed such limits. 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 ======================================================================== 39 Received: by NERVM (Mailer R2.07) id 9796; Thu, 06 Dec 90 14:32:52 EST Date: Thu, 6 Dec 90 14:30:58 -0500 Reply-To: yeongw@psi.com Sender: "Z39.50 Implementors Workshop" From: yeongw@SPARTACUS.PSI.COM Subject: Re: Length restrictions in ASN.1 X-To: "Z39.50 Implementors Workshop" To: "MARK HINNEBUSCH, FCLA" In-Reply-To: Your message of Thu, 06 Dec 90 13:22:53 -0500. <9012061835.AA06538@psi.com> > John's suggestion to look at the ASN.1 standard was a good one. The SIZE > constraint is exactly what is needed. If lengths are to be constrained within the ASN.1, SIZE would certainly be an appropriate method to do so. However I will argue here that the length constraints should not be made part of the standard. > > We would, however, have to agree on > rational size limitations to put into the ASN.1. As you point out, arriving at 'rational' size limitations would be problematic. Apart from the differing needs of current implementations, I'm concerned that introducing size limitations in the standard, will limit the usefulness of the standard in the future. It is a truism that technologies change, and today's 'supercomputer' is tomorrow's paperweight: remember 'state of the art' IBM PCs with 64K of RAM? 'State of the art' networks with 9600bps links? 'State of the art' operating systems that had 32 bit address spaces? :-) :-) I view Z39.50 as a still-evolving standard, and I'd argue that any size limitations we can arrive at now is going to look pretty ridiculous when it matures. I think the 'right' thing to do here is to make size limitations an implementation-specific issue, and just return a diagnostic. Wengyik ======================================================================== 26 Received: by NERVM (Mailer R2.07) id 9130; Thu, 06 Dec 90 13:36:59 EST Date: Thu, 6 Dec 90 13:22:53 EST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Length restrictions in ASN.1 To: "MARK HINNEBUSCH, FCLA" OK, I'll go along with arbitrarily long result-set-IDs. However, I don't think we can ignore the length issue because EVERY implementation has some length limitations even if they are so great as to be essentially non-existent. I've been in this business long enough to know they will get hit anyway. John's suggestion to look at the ASN.1 standard was a good one. The SIZE constraint is exactly what is needed. We would, however, have to agree on rational size limitations to put into the ASN.1. While I think that is worth doing, it is problematic. For instance, I cannot currently accept searches in excess of 32K characters. Seems reasonable... However, Franklin is probably going to want to throw "chunks" bigger than that at his engine. A size limitation in the ASN.1 definition to protect me (and probably most bibliographically-oriented systems) would kill him. So, I propose that we work out (or someone offers a set of) some diagnostics for this condition. If all agree to the diagnostic message solution, I will try my hand at defining some. ======================================================================== 101 Received: by NERVM (Mailer R2.07) id 6495; Tue, 04 Dec 90 17:35:18 EST Date: Tue, 4 Dec 90 17:33:17 -0500 Reply-To: z3950iw@nervm.nerdc.ufl.edu Sender: "Z39.50 Implementors Workshop" From: yeongw@SPARTACUS.PSI.COM Subject: Z39.50 Protocol Implementation Questions X-To: z3950iw@nervm.nerdc.ufl.edu X-cc: yeongw@psi.com To: "MARK HINNEBUSCH, FCLA" In trying to implement Z39.50 Version 2, I've hit a few snags, and have a few questions with respect to both the protocol and "correct" (ie., interoperable) implementation decisions. 1) If an origin specifies a preferred record syntax in a Search or Present that is not supported by a target, what error gets returned? My preference would be for present status to have value "failure" and for a diagnostic record to be returned, but there doesn't seem to be an appropriate diagnostic code in "niso ... bib-1". Closest I could find was diagnostic 14 (system error in presenting records). 2) What's the value of the oid to be used as the direct reference id for the user information field in the Init Request/Response? I'm assuming that the format of the user information field is not subject to presentation negotiation. Is that correct? 3) How is support for result set naming related to support for multiple coexisting result sets? In the Z39.50 model, can it be assumed that if a target supports the naming of multiple result sets (and thus has the ability to disambiguate results sets), that it will keep more than one result set around at a time? For the purposes of this question, please exclude the unilateral deletion of result sets by a target due to "special circumstances". 4) What are the actual oid component values associated with "niso standard z39.50 attribute-set(3) bib-1 (1)", "niso ... diagnostic-set(4) bib-1 (1)"? I know the former ends with 3.1, and the latter with 4.1, but what about the other oid component values (what's the numerical component associated with the object descriptor 'niso'? with the object descriptor 'z39.50'?) 5) If a search is successfully executed on the target system, but yielded no results, did the search: a) fail b) succeed, and yield a result set with 0 records Does the result set actually exist? 6) Related to (5), if, on a target that supports result set naming a search request arrives that 1) names an existing result set as the name of the new result set 2) has the replace indicator set to true 3) results in a search yielding 0 results ... does the result set named in the search request contain 0 results, or the previously existing results? 7) What error is returned if a search request arrives specifying a search on one or more databases that do not exist on the target? 8) What's the application context id used in establishing an assocation between an origin and a target? What's the PCI? I know these are just constants, but if we all use different constants interoperability just went out the door :-) RLG has already argued that there is no need to define a presentation context (in the comments on SR). To be honest, I didn't understand why, but didn't say anything because I was probably misunderstanding something somewhere. Since Z390.50 (and SR) make direct use of Presentation services (P-DATA, to send/receive), it seems like a presentation context should be established. 9) What are some of the legal preferred record syntaxes that target implementations propose to accept? Since I suspect that USMARC will probably be a very common record syntax, what's the oid that should represent USMARC? 10) In general, are implementors planning on introducing implementation-specific limitations that will be visible to the other party (the origin, for a target implementation or vice versa)? A limit on string lengths and names? A limit on the depth of the Type-1 query tree? A limit on the number of records that can be returned (independent of message size limitations)? This is actually a generalization of Mark Hinnebusch's question about result set id lengths. For my part, I have no problems supporting arbitrarily long strings and names, but in practice, my origin will almost never send anything longer than 15-20 bytes for a name, so the 80 byte limit suggested by Mark is more than generous. In general, to what extent should I, as an implementor "fill in the blanks" with respect to constants (such as application context id, PCI, record syntaxes) from SR? I have no problems doing this, as long as everybody uniformly does the same. Thanks. Wengyik ======================================================================== 178 Received: by NERVM (Mailer R2.07) id 0521; Wed, 05 Dec 90 09:11:06 EST Date: Wed, 5 Dec 90 09:07:46 -0500 Reply-To: yeongw@psi.com Sender: "Z39.50 Implementors Workshop" From: yeongw@SPARTACUS.PSI.COM Subject: Re: Answers to some of Mr. Yeong's Z39.50 Protocol Implementation Questions' X-To: "Z39.50 Implementors Workshop" X-cc: yeongw@psi.com To: "MARK HINNEBUSCH, FCLA" In-Reply-To: Your message of Tue, 04 Dec 90 17:07:22 -0800. <9012050110.AA10041@psi.com> Thanks for the responses, Mr. Davison. > "1) If an origin specifies a preferred record syntax in a Search or > Present that is not supported by a target ..." > > This should NEVER happen. The record syntaxes to be used during an > association should be negotiated during Association Establishment. > Each record (abstract) syntax needs to be paired with a transfer > syntax. This is a presentation layer function. Maybe I'm missing something or was unclear, but I don't see record syntaxes as subjects of presentation negotiation. Given an understanding of the OSI Reference Model (that may admittedly be faulty), it seems like record syntaxes are an application layer issue, and thus should not be subject to negotiation in the presentation layer. I always thought that the presentation context list was intended for the negotiation of possible transfer syntaxes for protocol data elements, not for the data contained in the protocol elements. That is, in the case of an application that uses Z39.50/SR ASEs and the ACSE, the presentation context list should contain two contexts: the pairing of the abstract syntax/transfer syntax used to define Z39.50/SR PDUs (ie. ASN.1/BER); and the abstract syntax/transfer syntax used to define ACSE PDUs (which happens to be ASN.1/BER also). I actually think that record syntaxes are an Explain issue, and should not be negotiated at all. After all, it's not as if there is anything to negotiate: for a given database, either the target supports a record syntax or it doesn't. But in that case, there is a need for a diagnostic beyond just "user friendly" issues to deal with the possibility that an origin will request an unsupported record syntax. > "2) What's the value of the oid to be used as the direct reference > id for the user information field in the Init Request/Response?" > > I don't believe that we have developed any abstract syntaxes for > this field yet. What are you planning to use it for? Any such > abstract syntaxes would need to be registered and given an oid, > which would then be included as part of the encoding of the EXTERNAL > reference. Actually, I don't. In this implementation cycle at least, my origin will never generate an InitRequest that contains a user information field. However since the InitResponse also contains a user information field, I'm trying to determine what I might be getting back from a target. I cannot determine at more than the crudest level what the contents of a user information field mean without being able to recognize the direct ref. id and knowing the semantics associated with it. I'll be content and give up if, for the time being, we all agree not to exchange user information. I do however think that this needs to be addressed eventually (I'm probably preaching to the choir here, but oh well ... :-)). > "4) What are the actual oid component values associated with "niso > standard z39.50 ..." > > This is an interesting question. Until there are U.S. registration > authority procedures in place, there is no mechanism for creating > these oids. We will either have to make something up for the > interim, or try to piggy-back off of ISO 10163, which uses the > already existing procedures for registering things within an ISO > standard. I'll state right up front that I don't care, as long as we all use the same oids. That said, let me suggest an semi-official registration authority: the ISODE tree. It would be fairly easy to get the keepers of ISODE to assign a oid subtree to the Z39.50 effort. In fact, PSI Inc. (actually NYSERNet Inc.) already has one: 1.17.4.3.32, which I'm the keeper of. Although I'd prefer that the ZIG get one of their own so as not to complicate things in the PSI subtree, I'm perfectly willing to assign some subtree of 1.17.4.3.32 to the ZIG if necessary. I realize the ISODE tree isn't 'official', and ISODE certainly doesn't define the world of OSI implementations, but doing things via the ISODE tree has been successful in the arena of Directory pilots: both the U.K. and PSI Directory Pilots have oid assignments from 1.17. I don't see that, at least in the interim until the proper registration procedures get set up, Z39.50 development efforts should be any less successful. Getting an subtree assignment is pretty easy: send email to Marshall Rose :-). I'll volunteer to do it if nobody else wants to. Almost certainly easier than getting an assignment from ANSI (which, I'll argue is the proper place for the niso subtree). > "5) If a search is successfully executed on the target system, but > yielded no results ..." > and > "6) If ... a search request arrives that 1) names an existing result > set as the name of the new result set, 2) has the replace indicator > set to true, 3) results in a search yielding 0 results ..." > > It is unclear what happens in this case. My preference would be to > provide for a way to signal that the search resulted in 0 hits, and > to retain the previous result. Many systems work this way. Again, as long as we all agree ... > "8) What's the application context id used in establishing an > association between an origin and a target? What's the PCI? ... > ... need to define a presentation context ..." > > As in 4) above, we currently have no way to register the oids for > application contexts we develop. Again, we could make up something > in the interim, or piggy-back on ISO 10163. The application-context > is exchanged in ACSE protocol, and it is defined there as an oid. The ACSE protocol defines the context id for the ACSE. I believe we need another one for the Z39.50 ASE (much like the 'sr-A-context' oid in Annex C of 10163). Making one up is fine, as long as we all agree ... (usual text about interoperability :-)). > Presentation contexts are established dynamically as part of the > process of setting up the Application-Association and Presentation- > Connection. Presentation contexts have no meaning or existence > outside of a given Presentation-Connection. When the application > layer gives Presentation a Presentation-context-definition-list > (composed of abstract syntax identifiers) the Presentation Layer > responds with a list of associated presentation contexts, e.g. 1, 2, > 3, etc. I agree with everything in the previous paragraphs. The source of my ignorance is this: since the Z39.50 ASE uses Presentation services directly, isn't it necessary for it to define a context within which it will use said services, by defining a presentation context? (I'm not disagreeing with you, Mr. Davison, this is a question). I may have used incorrect terminology by referring to the oid as a PCI, sorry. I get a little confused by all the terms sometimes: basically I meant the oid passed down to the Presentation layer, and not the integer passed back up in referring to PCI, regardless of whether PCI actually refers to the oid or the integer (I actually think it refers to the oid but could be wrong). > "9) What are some of the legal preferred record syntaxes ... " > > Here we can piggy-back on ISO 10163, which does "register" oids for > USMARC and some others. OK, I can live with that. > "10) ... implementation-specific limitations that will be visible > to the other party ..." > > Agreements should be documented in a standards application profile, > and stated in the PICS for each implementation. Sigh. The issue of PICS in general makes me very uncomfortable. I agree that a PICS is the correct place for documenting implementation specific limitations, but the concept of using a PICS to fill in 'holes' not related to implementation makes me very uncomfortable. I would rather that other holes be fixed in the standard, rather than by means of PICS. For example, I believe the ambiguity about what happens when a search yields 0 results should be fixed in Z39.50/SR, and not in a PICS (I'm not implying that anybody disagrees with me in this instance, but am just using it as an example). By the way, are we implementing to Z39.50 Version 2, or to SR plus U.S. Ballot changes?? Wengyik ======================================================================== 35 Received: by NERVM (Mailer R2.07) id 8463; Tue, 04 Dec 90 20:32:19 EST Date: Tue, 4 Dec 90 17:31:47 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "John A. Kunze" Subject: Re: Length of result-set-ID To: "MARK HINNEBUSCH, FCLA" We could debate limitations on ResultSetId's for a long time, come up with a special diagnostic for when it was too long, and perhaps negotiate the size with extra Init parameters and a new option bit. This seems like alot of work just to produce or deny a restriction that we may one day regret. Once that is done, someone may raise the same questions about ImplementationId, Implementation... (etc), ReferenceId, and perhaps related questions about ElementSetName, DatabaseName, etc. Is there any wisdom we can gain by asking general questions first? As an aside, can we express size limitations in ASN.1? I see something promising in the vicinity of clauses 36 and 37... Everyone will have some real limits on their target and origin systems for any number of parameters, whether or not we claim to handle arbitrary length anything. It seems therefore that we'll need some diagnostics. What I don't want to do right now is consider individual diagnostics without setting up a framework that anticipates the more general questions. I personally like the fiction of arbitrary length and would need a very compelling reason to voluntarily set limits at this point. Who knows what I may want to convey to myself in the ResultSetId? Maybe I want it to contain the query that created it. John ======================================================================== 88 Received: by NERVM (Mailer R2.07) id 8161; Tue, 04 Dec 90 20:05:51 EST Date: Tue, 4 Dec 90 17:07:22 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Wayne Davison Subject: Answers to some of Mr. Yeong's Z39.50 Protocol Implementation Questions' X-To: z3950iw@nervm.nerdc.ufl.edu To: "MARK HINNEBUSCH, FCLA" REPLY TO 12/04/90 14:50 FROM Z3950IW@NERVM.NERDC.UFL.EDU: Answers to some of Mr. Yeong's Z39.50 Protocol Implementation Questions' Here are my answers to some of your questions. "1) If an origin specifies a preferred record syntax in a Search or Present that is not supported by a target ..." This should NEVER happen. The record syntaxes to be used during an association should be negotiated during Association Establishment. Each record (abstract) syntax needs to be paired with a transfer syntax. This is a presentation layer function. If a target received a request to use a preferred record syntax that was not already included in the Presentation Context Definition List, the target could legitimately ABORT. We might still want to be "kinder and gentler" and issues a diagnostic. "2) What's the value of the oid to be used as the direct reference id for the user information field in the Init Request/Response?" I don't believe that we have developed any abstract syntaxes for this field yet. What are you planning to use it for? Any such abstract syntaxes would need to be registered and given an oid, which would then be included as part of the encoding of the EXTERNAL reference. "4) What are the actual oid component values associated with "niso standard z39.50 ..." This is an interesting question. Until there are U.S. registration authority procedures in place, there is no mechanism for creating these oids. We will either have to make something up for the interim, or try to piggy-back off of ISO 10163, which uses the already existing procedures for registering things within an ISO standard. "5) If a search is successfully executed on the target system, but yielded no results ..." and "6) If ... a search request arrives that 1) names an existing result set as the name of the new result set, 2) has the replace indicator set to true, 3) results in a search yielding 0 results ..." It is unclear what happens in this case. My preference would be to provide for a way to signal that the search resulted in 0 hits, and to retain the previous result. Many systems work this way. "8) What's the application context id used in establishing an association between an origin and a target? What's the PCI? ... ... need to define a presentation context ..." As in 4) above, we currently have no way to register the oids for application contexts we develop. Again, we could make up something in the interim, or piggy-back on ISO 10163. The application-context is exchanged in ACSE protocol, and it is defined there as an oid. Presentation contexts are established dynamically as part of the process of setting up the Application-Association and Presentation- Connection. Presentation contexts have no meaning or existence outside of a given Presentation-Connection. When the application layer gives Presentation a Presentation-context-definition-list (composed of abstract syntax identifiers) the Presentation Layer responds with a list of associated presentation contexts, e.g. 1, 2, 3, etc. "9) What are some of the legal preferred record syntaxes ... " Here we can piggy-back on ISO 10163, which does "register" oids for USMARC and some others. "10) ... implementation-specific limitations that will be visible to the other party ..." Agreements should be documented in a standards application profile, and stated in the PICS for each implementation. To: Z3950IW@NERVM.NERDC.UFL.EDU ======================================================================== 15 Received: by NERVM (Mailer R2.07) id 7869; Tue, 04 Dec 90 19:53:01 EST Date: Tue, 4 Dec 90 16:52:08 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Michael Thwaites Subject: Length of result-set-ID To: "MARK HINNEBUSCH, FCLA" In practice I can't see any need for long result-set-ids. I would think 8 or 16 characters would do. Don't you realy need a diagnostic for 'Invalid result-set-ID' instead of just 'invalid length of result-set-ID'? For instance, a server may find imbedded blanks a problem or may only support non-numeric result-set-IDs. ======================================================================== 101 Received: by NERVM (Mailer R2.07) id 6495; Tue, 04 Dec 90 17:35:18 EST Date: Tue, 4 Dec 90 17:33:17 -0500 Reply-To: z3950iw@nervm.nerdc.ufl.edu Sender: "Z39.50 Implementors Workshop" From: yeongw@SPARTACUS.PSI.COM Subject: Z39.50 Protocol Implementation Questions X-To: z3950iw@nervm.nerdc.ufl.edu X-cc: yeongw@psi.com To: "MARK HINNEBUSCH, FCLA" In trying to implement Z39.50 Version 2, I've hit a few snags, and have a few questions with respect to both the protocol and "correct" (ie., interoperable) implementation decisions. 1) If an origin specifies a preferred record syntax in a Search or Present that is not supported by a target, what error gets returned? My preference would be for present status to have value "failure" and for a diagnostic record to be returned, but there doesn't seem to be an appropriate diagnostic code in "niso ... bib-1". Closest I could find was diagnostic 14 (system error in presenting records). 2) What's the value of the oid to be used as the direct reference id for the user information field in the Init Request/Response? I'm assuming that the format of the user information field is not subject to presentation negotiation. Is that correct? 3) How is support for result set naming related to support for multiple coexisting result sets? In the Z39.50 model, can it be assumed that if a target supports the naming of multiple result sets (and thus has the ability to disambiguate results sets), that it will keep more than one result set around at a time? For the purposes of this question, please exclude the unilateral deletion of result sets by a target due to "special circumstances". 4) What are the actual oid component values associated with "niso standard z39.50 attribute-set(3) bib-1 (1)", "niso ... diagnostic-set(4) bib-1 (1)"? I know the former ends with 3.1, and the latter with 4.1, but what about the other oid component values (what's the numerical component associated with the object descriptor 'niso'? with the object descriptor 'z39.50'?) 5) If a search is successfully executed on the target system, but yielded no results, did the search: a) fail b) succeed, and yield a result set with 0 records Does the result set actually exist? 6) Related to (5), if, on a target that supports result set naming a search request arrives that 1) names an existing result set as the name of the new result set 2) has the replace indicator set to true 3) results in a search yielding 0 results ... does the result set named in the search request contain 0 results, or the previously existing results? 7) What error is returned if a search request arrives specifying a search on one or more databases that do not exist on the target? 8) What's the application context id used in establishing an assocation between an origin and a target? What's the PCI? I know these are just constants, but if we all use different constants interoperability just went out the door :-) RLG has already argued that there is no need to define a presentation context (in the comments on SR). To be honest, I didn't understand why, but didn't say anything because I was probably misunderstanding something somewhere. Since Z390.50 (and SR) make direct use of Presentation services (P-DATA, to send/receive), it seems like a presentation context should be established. 9) What are some of the legal preferred record syntaxes that target implementations propose to accept? Since I suspect that USMARC will probably be a very common record syntax, what's the oid that should represent USMARC? 10) In general, are implementors planning on introducing implementation-specific limitations that will be visible to the other party (the origin, for a target implementation or vice versa)? A limit on string lengths and names? A limit on the depth of the Type-1 query tree? A limit on the number of records that can be returned (independent of message size limitations)? This is actually a generalization of Mark Hinnebusch's question about result set id lengths. For my part, I have no problems supporting arbitrarily long strings and names, but in practice, my origin will almost never send anything longer than 15-20 bytes for a name, so the 80 byte limit suggested by Mark is more than generous. In general, to what extent should I, as an implementor "fill in the blanks" with respect to constants (such as application context id, PCI, record syntaxes) from SR? I have no problems doing this, as long as everybody uniformly does the same. Thanks. Wengyik ======================================================================== 16 Date: Tue, 04 Dec 90 12:49:12 EST From: "Mark Hinnebusch, FCLA" Subject: Length of result-set-ID To: "Z39.50 Discussion List" I know that the protocol does not limit the length of result-set-ID, but is anyone planning to support arbitrarily long strings? If an installation places limits on the size of a result-set-ID, how do you handle an excess length? It seems to me that a new diagnostic would need to be added to {NISO standard Z39.50 Diagnostic-set (4) bib-1 (1)} with a meaning of "Result-set-ID too long". While I could support arbitrarily long strings, I see no advantage to it and there are some simplicities to be gained in limiting it to, say, 80 characters. At the same time, code would have to be added to handle the diagnostic. How say you all?