Minutes from the Z39.50 Implementors Workgroup meeting at the Embassy Row Hotel in Washington, D.C., April 14-16. Bill Cattey has sent me his notes from the meeting. I'll insert mine in CAPS with his. I don't notice any significant difference between our notes. Thanks again to Craig Summerhill and CNI for hosting the meeting! Ralph LeVan Largest turnout yet! New Faces: University of Wisconson CD Plus Princeton University Microfilms Inc. University of Mo. Auto Graphics West Publishing Silver Platter ---- Progress report issues: AT&T, now that usage is ramping up bigtime, management and vendors are worried. Clearly lots of people are using the data, but lack of centralized control over who gets access is becoming a worry. NOTIS now uses OPAC extensions. Software Kineti cs's implementation is well along! Coding is nearly done. Expect to be distributing by next ZIG. DRA API done, and now there's a swarm of application programmers at work with it. (Also working on Image Support.) I MADE SOME NOTES ABOUT THE STATES OF THE SERVERS. MDC - IN PROGRESS CARL - RUNNING UCDLA - USING DRA'S SERVER FCLA - RUNNING ON TOP OF OSI STACK OCLC - RUNNING AT&T - RUNNING U OF WISC - BY END OF YEAR VTLS - IN PROGRESS RLG - RUNNING NOTIS - RUNNING NLC -IN PROGRESS CAS - IN PROGRESS USING UCB'S SERVER UCB - RUNNING GAYLORD - RUNNING DRA - RUNNING LC - TESTING MIT - USING OCLC'S SERVER ---- V3 Draft 6 discussion: Extensibility issue: For many services, if the target specifies 'in-effect' for the service option, the origin is permitted to initiate the service even if the origin did not initially set the "in-effect" option bit for for it. There are some situation where receiving the option bit set in the init response from the target means "you must use this feature even if you didn't set it in your Init request". This is a requirement for operation of Access Control and Resource Control. (Origin didn't want to do access control but is told that the Target needs it, so the origin goes a head now and does it.) If the origin says it is Version 3, then it is understood that all the option bits are understood, so that this expanded permission stuff will work. If the origin says it is Version 2, the target must guarantee that it doesn't set any v3 options in response. Otherwise it should fail the connection. OPTION BITS DISCUSSED AND VERSION COMPATIBILITY. VERSION 2 CAN BE EXTENDED WITH VERSION 3 BITS. SORT: WANT A RESULT-SET-STATUS PARAMETER THAT WILL BE RETURNED WHEN THE SORT-STATUS IS "FAILURE". Scan "Term Match" issue: The prose "appears but not with exact match" is problematical. People agree that it doesn't adequately describe the definition of the ways in which partial match might occur. (We don't even remember where Term Match came from.) Preference is to KILL the term match parameter. DROP TERM-MATCH FROM SCAN. Scan "Database ID" issue: Does this mean that there is a requirement that no other databases will provide results? Yes. Ray will work with Ralph and Joe on wording. EXPAND PROSE FOR DATABASE-ID FROM SCAN. Segmentation issue: Ray says that the prose will be simpler if we say "if segmentation 2 is in effect, maximum record size does not apply." He will rewrite the section and we'll see if it is simpler and a better way to say it. Fragmentation issue: It is definitely permissible to not fill an entire record if the target prefers to partially fill the fragment and overflow into the next record. Stated another way, although segmentation2 is on arbitrary byte boundries, no requirement exists to fill every record up to the preferred record size. (Mark objects to the use of the word "term" in the example.) The prose will change to better show the discretion that the target can exercise. EXPAND PROSE IN ILLUSTRATION OF L2 SEGMENTATION TO SUGG EST ARBITRARYBYTE SEGMENTATION. Model of reassembly issue: The prose in 3.2.3.1.6 should be weakened so that it doesn't imply that the protocol isn't requried to do the reassembly -- that it could be being done by the application. "Operations" issue: Section 3.4 seems to be in the wrong place. The definition of and "operation" will go into Definitions section. Section 3.4 will move to nearer the beginning. Reference-id has come to have a second meaning: an opague token which has no meaning within the standard which can be included in pdus for holding associated opague data for the origin. We're going to leave this as is for now, since there are not a lot of implementors who are overloading the Reference-ID. However we expect we'll get bit by this in the future. NO CHANGE TO REFERENCE-ID. OID Issue: In an element specifier, do we want to also have an Object ID in addition to the External for an element set name? Yes. But not now. Or was this an issue of dropping the PrimitiveEsn component? In any event, there is no change. Adjacency issue: For the simple case of two key words next to each other, figuring out if the target supports that sort of query is very hard. WDC will propose an explain flag that will identify this, and rigorously enough define the adjacency special case of PROX. Range Issue: Someone will draft an amendment to make ranges in concurrent operations explicit. Rank in result set issue: There was talk of returning result set rank data along with the result set. But "Rank" needs to be defined. Various nits in the ASN.1.... ---- Extended Model Discussion: Clifford has some problems with the language. He will formulate changes off-line and propose them. He will also propose a few items for discussion. CLIFF WILL COUNTERPROPOSE EXTENDED MODEL PROSE JOHN WILL COUNTERPROPOSE BASIC MODEL PROSE Result set Restriction Discussion: The example (as with the Proximity examples) seem to be more focused upon a specific implementation rather than on the standard. Some work to help clarify some of the ambiguities seems in order. Disclaimers of the form "This example is just an example" really don't cut it! Restriction needs to be as well as defined as attributes-plus-term. (However it is an ostensibly ambiguous feature.) We need to gain implementation experience with this feature. We expect our understanding to evolve. More discussion to follow on the list and in a subgroup. Ray will motivate some discussion. A LONG DISCUSSION ENSUED ABOUT AMBIGUITY IN Z39.50. TO BE CONTINUED ON THE LIST SOON. THE ASN.1 IS O K. Close service Discussion: Remember: although you can always ABORT, it's polite to CLOSE rather than ABORT upon receipt of a CLOSE. FOLKS WERE HAPPY. ---- Anybody interested in putting together an Implementor's Workshop, either at ALA or before a ZIG? Yes. Jim Michael is interested in putting together a Non-technical description of Z39.50. Next ZIG is July 7,8,9 in St. Louis at the Radisson. (Special rate, $89 if you say you're with DRA or Z39.50 group.) There may be an implementor's technical workshop the 5th &6th. MY NOTES SAY JUST 1 DAY OF WELCOME TO Z39.50, PROBABLY ON THE 6TH. The ZIG after that is in Ottawa on October 4,5,6. FOLLOWING MEETING WILL BE JANUARY 26, 27, 28. LOCATION TBD. In April, plan a ZIG in North Carolina, perhaps. (ALA is when?) ---- Explain Discussion: There are emerging a couple different models of how people will want to use/access the explain information. (A relational model is emerging.) Record-Field-Info will list all the fields. There may be additional records for each field for more detail. (We're decomposing the Record-Field-Info record but still allowing it to be viewed as a composite of it's components.) A subgroup will go over the other records to see what others need decompostition (and report back before the end of the ZIG). Ray has a concern about clarifying what the explain extensibility is. Do we need an Explain Attribute set? It doesn't matter, as long as we get the attributes we need from somewhere. STILL NOT FINE ENOUGH GRANULARITY. UNABLE TO DETERMINE POSSIBLE RECORD COMPOSITION. EXTENSIBILITY WAS DISCUSSED. ASN.1 SOON. SEARCHING DISCUSSED. LANGUAGE OF RETRIEVAL DEFERRED. ---- Info-1: New ASN.1 handed out for ES-1 and Generic Record syntax. Global Attribute set is an outgrowth of discussion at Florida ZIG. Dynamic attribute semantics are discovered through Explain. If you don't have access to Explain, use Generic Record syntax. Much discussion of the scope of Info-1 and Global Attrib set. At issue: who defines and how is defined the meaning of combinations across the attribute sets. Kunze has an idea for a global set of rules for evaluation of attributes in attribute list. (A logical level above attribute sets but below the level of query.) Ralph disputes that such a global specification is possible. If the scope is limited to a way that attribute set authors can ELECT to enable their attribute set to work with others, Kunze's global attribute set is *a* solution to an important problem of interoperability of attribute sets in combination. The problem of mixing things from multiple attribute sets looks like it can be addressed in these ways: Rules for how all sets mix. Controlling attribute set with rules for incorporating others. Overriding definitions within an attribute set. Let server define how it would work. Ralph opines that Clients that combine attribute sets are specialized. OOPS BIB-1 seems to say nothing about multiple attributes hanging off a term. Larry, Kunze, and Hinnebush will work out a proposal to enhance BIB-1 for rules of engagement (combination, missing term, but NOT semantics). Larry, as editor of BIB-1 will have veto power. The steering committee will get an estimate on the time for the proposal, and set a due date. ---- Much discussion on variant fields and whether they define a whole syntax The intent is to prevent the explosive proliferation of record types and instances. ---- There seems to be support for the Generic Record, but people need more time to get comfortable with it. A subgroup will need to define what parameters in a present PDU look like. GLOBAL ATTRIBUTE SET: A LONG DISCUSSION ENSUED ABOUT THE MEANING OF ATTRIBUTES. ---- LUNCH WAS VERY NICE! ---- ATTRIBUTES: JOHN LARRY & MARK WILL DEFINE BIB-1 SEMANTICS. GLOBAL ATTRIBUTE SET DEFERRED TO LATER MEETING. GENERIC RECORD: A LONG DISCUSSION OF VARIANTS ENSUED. RECORD STRUCTURE DISCOVERY METHODS WERE DISCUSSED. ES-1 WAS DISCUSSED INCONCLUSIVELY. A SUBGROUP WILL DISCUSS THIS FURTHER. EXTERNAL TAG SETS ARE NEEDED. SYNTAX-ELEMENTS PARAMETER OF SEARCH WAS DISCUSSED AND MAY BE OVERLY COMPLEX, BUT WILL STAY AS IS. ---- Extended Services We must not understand this, there was not much discussion... WAS NOT OBJECT ED TO, NOR WAS IT ROUSINGLY ENDORSED. DESCRIPTIONS OF PARAMETER PACKAGES WILL BE PROVIDED. ARE DATABASE NAMES CASE SENSITIVE? DIAGNOSTICS WILL BE BROADENED. TARGET MAY ASSIGN A NAME TO A PARAMETER PACKAGE AND RETURN IT TO THE USER. U.S. WILL PROPOSE USING EXTENDED SERVICES TO WG40 FOR DATABASE UPDATES. ASCII Record Syntax Discussion: Question of whether or not this is a transfer syntax. You can define a record structure with an abstract syntax and say the transfer syntax is 'ASCII'. The problem at hand is how to get formatted ascii (say for display on a 24x80 string) from the Target. This may or may not be possible to set up with ES-1. Small group, "The Syntax group" formed to sort this out offline. Kunze, Les, Sean, Ralph, Peter, Ray, Dennis, Needleman, and ??? Much pointless discussion ensued. CONFUSION REIGNED OVER THE MEANING OF RECORD SYNTAX. NO IMMEDIATE SOLUTION WAS PRESENTED TO LES' REQUIREMENT. TO BE SOLVED OFFLINE. ---- TIFF Syntax -- Same problems as ASCII display issues. Same solutions. ---- Authentication: The syntax for ID authentication in INIT is a profile issue. There is a need for a uname/passwd record definition, and a plain string in addition to the external definition. ZIG ID_Authentication ::= CHOICE { -- userid may be "anonymous" open [1] VisibleString -- may be username'/'passwd userpass [2] SEQUENCE { userid [1] VisibleString OPTIONAL password [2] VisobleString OPTIONAL } anonymous [3] NULL other [4] EXTERNAL } -- other is same as Access Control responses -- ANONYMOUS ACCESS SIGNALLED BY ABSENCE OF ID-AUTH OR STRING "ANONYMOUS". EXTERNALS WILL BE THE SAME AS ACCESS CONTROL. ---- Chargeback info from clients: (how the origin tells the target how to bill) Origin could send chargeback info through Extended Services. This means that we're now saying that it's ok to have Resource Control trigger an Extended Services request. RECOMMENDED THAT IT BE ACCOMPLISHED USING RESOURCE CONTROL FROM TARGET TO TRIGGER THE ORIGIN TO SEND AN EXTENDED SERVICES REQUEST WHICH CONTAINS THE ACCOUNTING REPORT. EXTENDED SERVICES REQUEST CAN ALSO BE ISSUED UNILATERALLY BY THE ORIGIN. ---- Stop Words: REporting that a stop word got zero postings can be reported in the Associated-Seaarch-Info. This field needs to be fleshed out. Ralph, Clifford, Les, Bob and Bill will be looking at this. DITTO. ---- ZIT: Visible and interoperable Z39.50 is demonstrated. We declare Victory. There is a desire to go out with a bang, perhaps at ALA. "Z39 in Plain English" paper is under revision. <-- Hand out many copies of it at ALA. Would any ALA attendees be interested in demonstrating other connectivity? Jim, Sara, and Hinnebush are speaking at the Tesla program. After ALA, the ZIT goes away. When V3 comes along, a NEW ZIT will be formed. (A call for participants would be issued for this new Task-oriented group.) We expect that the ZIG will shift focus to implementation and production (and become a profile writing group) when the V3 standard goes to ballot, before V4 work begins. DITTO. ---- IETF: We should put something on Z39.50 for the IETF template. (After all, they've got something there on X.500...) Needleman will draft something and circulate to the list. DITTO. ---- WG4 Meeting: ISO TC46 Working group 4 -- Responsible for SR. On the Agenda: SCAN (pretty far along), Access and Resource control, Suspend/Resume (US position is we don't like it but really don't care if it gets tacked onto SR.) We recently submitted papers for Proximity, Segmentation and Concurrent Operations. (Close was bundled in with Concurent Operations.) Our position on the Access Control Cost limit parameter is that our experience that it's not useful. (It's optional so we can profile it out.) What else should we bring forward? Explain -- YES. We'll bring a paper on it. Sort -- (How mature is it?) Yes. Restriction is not a part of Proximity, but the Extended model is. Bringing Extended Services, not as a mature service, but as motivation for UPDATE. DITTO. ---- Object Registration: Object classes: 1-7 are already defined on pg 34 of v2. Both diagnostic record and diagnostic record set are under 4. 8. Access control formats / ID Authentication 9. Extended Services 10. User Informatin/ Otherinformation/ additional information. 11 Element set definitions OID Abstract element set definitions Concrete registered elements Public/Local/Private Issue: Local definitions can be Private. MAINTENANCE AGENCY WILL PUBLISH PRIVATE OBJECT ID'S THAT ARE AVAILABLE FOR PUBLIC ACCESS. ---- Register of Implementors: Is this useful? Has it been subsumed by other registries? YES it is useful. It gives credibility to the movement. We may need more publicising and clarification of the registry -- perhaps through a "Welcome to the Z39.50 list" email doc that gets periodically sent out. It would be nice to put the registry online. Now is the time to update your entry! DITTO. ---- Draft 7 Acton plan: When do we want a ballotable draft? Having stable definitions is more critical than having them balloted. Implementation is going on in advance of the standard. Our experience is that the standard is not being de-stabilized by the advance implementation. We're implementing stable portions, and sanity checking the standards. Ballotable draft in early '94 is probably a reasonable goal. Conclusion: The way we're doing it now seems about right. There is a potential problem for people waiting for v3 before they begin implementing, but we don't see much of any members in this group. Now is the time to roll in the "from V2" sections. Diagnostic formats: Send list of diags to Ray. Access control Formats: Are people working on these? Yes. Peter will work on Kerberos ticket format. PRESSURE TO BRING DRAFT TO BALLOT HAS LESSENED BECAUSE IMPLEMENTORS ARE ACTING IN ADVANCE OF THE STANDARD. WE'D LIKE TO SEE A COMPLETE COPY OF THE DRAFT. SEND DIAGNOSTICS TO RALPH (RRL@OCLC.ORG). BRING OUT YOUR ACCESS AND RESOURCE CONTROL FORMATS. TARGET OF EARLY '94 FOR DRAFT BALLOT. ---- Profiles: Ralph has published a profile and is waiting for others to do so. For next time: Everyone submit their implementation profile to Ralph who will produce a profile that unifies the data. The PICS Pro Forma is one way to fill out the profile. (Or one could use Ralph's as a template.) What is the usefulness of the ZIG profile? Serves as tangible document of agreements we've ended up making amongst ourselves. Can (SHOULD) be factored back into the standards. Spending a lot of time to document behavior that is being rewritten and will go away seems ill-advised. (Except that it would serve as a good spec for others getting their NEW behavior right.) Profile also tells new implementors what parts of the standard are mandatory. The profiling should begin now. But it should begin informally, and generalize from there. LITTLE INTEREST IN THE OIW WAS EXPRESSED. THE IFOBS COPY OF THE SR PROFILE WILL BE CIRCULATED. ---- EXPLAIN ATTRIBUTE SET REVISITED: WILL BE CREATED, POSSIBLY COMBINED WITH EXTENDED SERVICES ATTRIBUTE SET. SEND ATTRIBUTES TO BOB.