Date: Fri, 16 Jul 1993 12:49:23 EDT From: Peter Ryall Subject: ZIG Meeting Minutes: July 7th (day 1) *************************************************************************** The following minutes are my attempt to capture the essence & key points of the most recent ZIG mtg held at the St Louis airport Radisson July 7-9. Thanks to Jim Michael, Sean Donelan, & all the other fine DRA folk who provided so bountifully & graciously for both the Z39.50 Implementor's Workshop & the ZIG meeting itself. Although these minutes are only intended to cover the ZIG mtg, I think I would be remiss if I didn't note that the Workshop was a raving success, & that it was masterfully organized & executed by all involved (not to be confused with saying that any of those involved were raving). I think special thanks should go to Sara Randall & Margery Tibbetts, and, having attended the Workshop, I would also like to congratulate the presenters for a very lucid, in-depth trek through both the mysterious & mundane elements of the Z39 protocol. I thought the examples were very real-world & understandable, & the detail service descriptions were lively & interesting enough to keep most of us awake (there are always a few who come because they need the rest)... While I'm on the subject of the Workshop, it was suggested on the last day of the ZIG that we hold follow-up in-depth sessions (primarily targeted to ZIG members, but others are welcome). These sessions would take an individual topic (like Record/Document/Abstract/Transfer syntaxes - heaven forbid - only for example purposes) & explore it in more detail in the form of a tutorial given by a recognized expert in the particular subject area. A half-day (4-hour) session was suggested for each of these tutorials, & it was also suggested that Bob Waldstein might do the 1st walk-thru tutorial on Explain at the Ottawa mtg - is my memory correct on this? Somebody please correct me if I'm experiencing premature Alzheimer's! I think there was also a discussion about holding another workshop for interested parties sometime in the future (possibly before the January mtg) but I didn't get any decision on this written into my notes - can someone clarify this. Speaking of the January mtg, although we have fairly firm dates (Jan 26-28) there was still some wavering about the location - some of warm-blooded folk were suggesting a more southern locale (such as CNIDR in NC) for a January mtg, but I think he Washington contingent was mumbling something about a snowball fight to resolve the record syntax dispute, so it appears this will be resolved over the list. Now for the real meat of the minutes, with apologies in advance for any inaccuracies, mistatements, misunderstandings, misspellings, or omissions - if you look closely you will no doubt find many of these... Peter Ryall We had by far the largest group yet - 65 at last count.. New players: AGFX ? Department of Energy (DOE) Digex ? National Library of Medicine (NLM/NIH) PSS ? Pittsburgh Syracuse WAIS Inc. WLN ? Also lots of new players at the pre-ZIG Workshop, but I'll leave that info to the Workshop gurus.. I apologize especially for errors & omissions in the above list, as I was not able to accurately transcribe each company/org name, & our attendance list did not have a separate column for comp/org/univ name this time, so I had to do some rather unscientific extrapolating & I also have the disadvantage of not knowing the library systems industry as well as most of you - this is the down side of having 1 of us non-bibliographic types (& a 'variant' person to boot) recording the notes.. ITEM 1) Introductions & Status Reports The Introductions went in rapid-fire cadence, so I probably missed major as well as minor details below (please correct the report where necessary): LC, Ralph Orlik - client & server fully operational, using DLA's BER code as a base. UC DLA, Margery Tibbetts - new attributes & DB's now, OPAC F/F later this month. Penn State, Eric Ferrin - 70,000 students now have access to RLG DB's via Penn State's V2+ clients - some V3 features implemented (such s OtherInfo) - working on other V3 features. DRA (thanks again for hosting!), Sean Donelan - same V2 clients & servers as reported at last ZIG, more DB's. OCLC, Ralph LeVan - V2 server & clients in production, new DB's, working on V3 features (sp. Scan) AGFX, Don Burns - nothing to report Autographics, Bob Marshall - no report GEAC, Xavier Trevisani - V2 server & client operational, working on Scan. GEAC, Andy Oates - graphical-oriented client, working on OPAC RLG, Lennie Stovel - Eureka client in production, server now sorts result sets - working on Scan U. of Wisconsin, Curt Ellman - working on V3 server - hope to have available w/in 8 months (? - couldn't read my notes) Software Kinetics, Joe Zeeman - working on fully integrating their new toolkit - toolkit available to other implementors FCLA, Terry Sullivan - current V2 implementation runs over TCP/IP, working on OSI implementation that uses SNACC compiler & run-time libraries (at least the Presentation layer) CMU, Greg Diskin, Parviz Dousti - working on V2/V3 clients & server (?) as part of Project Mercury CWIS @ CMU (Library Automation) NOTIS, Sara Randall - V2 MS-Windows client in Beta, working on Scan for V3, test servers, & MAC client Silver Platter, Andy Shapiro - currently have client/server ver sion of CD-ROM system w/proprietary protocol. Plan to support Z39.50, possibly via a gateway. WAIS Inc, Margaret St. Pierre - current WAIS server & clients based on modified Z39.50 V1. Plans to move directly to V3. VTLS, Cathy Winfrey - V2 Windows client DOE (Env Health/Safety), Mary Schonsberg - working on interfaces to E-mail systems & BBS's, plans to install Z39 (possibly as gateway?) Acadia U, Steve MacNeil - V2 Z39 server currently in Beta AT&T, Bob Waldstein - upgrading server & clien ts to V3D7 - currently testing Scan. U. of Missouri, Kurt Kopp - ? USGS, Tim Gauslin - have spent last 2 years working w/federal agencies on evaluating Z39.50 & how it can be used to interconnect agencies with each other & the public. Dialogue, David Loy - planning to implement Z39 V2/3 server ESL, Denis Lynch - working on Z39 clients (V3) CARL, Thorn Roby - V2 server now has 40 DB's accessible - V2 MAC client West Publishing, Richard Kasson, Cyndy Luk - working on V2 client to act as gateway to Dailogue. UCOP, Mark Needleman - Z39 between Melvyl & client (now fully operational) CNIDR, Jim Fullton - V2 server in final testing, MS-Windows client available Chemical Abstracts, Les Wibberley - V3 search now operational, Scan completed soon - 2 clients working (BER & ISODE based) - STAS available publicly Dartmouth, Eric Bivona - V2 origin implemented as a gateway on the backend. Gaylord, Brad McLean - V2 origin & target currently integrated into Galaxy - Sort & Scan available soon. Berkeley, John Kunze - V2 server & X windows client operational, working on V3 features (sp. concurrent operations) & multi-threading. CIA, Julie Mills - using WAIS Inc client, planning to move to V3 National Library of Medicine (NLM/NIH), Rick Rodgers - working on a mechanism to handle automated search server & DB selection. ************************************************************************ For the other agenda items, I used their original assigned #'s as 'URL's' so you can follow along with your copy of the agenda, but I put them in the sequence they were discussed (or at least I attempted to): Version 3 Topics: ---------------- ITEM 2) Version 3, Draft 7 (V3D7) walkthrough (Denenberg) This was an awesomely tedious (but highly necessary) agenda item which consumed the rest of the time until we adjourned around 5:45. I'd like to say (& I think I speak for the group) that we very much appreciate all of Ray's hard work in getting the various pieces of draft 7 pulled together in time for the mtg (& an early e-mail review). We especially appreciate the effort he went through to re-integrate & update the original sections from V2 - having a fully integrated draft is of priceless value to those of us who have had to spend great amounts of time in the past manually (and electronically) cutting & pasting various pieces of V2 into each V3 draft so we could circulate it & incorporate it into company design docs - now it is all there in one piece - albeit not perfect yet, but 1000% better than it was in earlier versions. thanks, Ray.. Ray made comments about the draft getting too large, but there was unanimous agreement that it should not be condensed or split into multiple docs, as its value in an integrated form far outweighed any awkwardness in working with it as a large doc. (am I slanting the views or was this the consensus?) General comments from Ray: - between last mtg & this one a subgroup worked on simplifying the record syntax model while separating variants & other sub-record representation requirements into 'Composition Specs' (discussed at lebgth in Item 10.5. - at 1st Ray said D7.x would only fix errors, but later he decided to include minor (obvious consensus) corrections - he also was applauded when he mentioned that he would put D7+ up on an FTP server (probably FCLA's) Sect 2) new V3 definitions - not yet re-integrated w/V2 definitions - also erred on the side of inclusion - will delete ones note needed - Ray wants comments on these! 3.1.3) Ray suggests that maybe we could put a model section on Search here in the spirit of 3.1.4 for Retrieval - he is welcoming ideas.. 3.1.4) some discussion about Transfer vs Abstract Syntax (deferred until Item 10.5) 3.2.1.1.1) protocol version changed to version. 3.2.1.1.3) rewritten. 3.2.2.1.7) DB/Diagnostic Records changed to Retrieval Records. 3.2.3.1.2) Additional Ranges (new) - supports multiple record ranges in Present - discussion about allowing Origin to select random ranges (overlapping & out-of-sequence); some felt current structure restricts Origin flexibility to select records in any sequence; others felt this was allowing too much flexibility & the order returned by the target would be non-deterministic & inconsistent; suggestion was made to return a relative record # for each record in RS - this was rejected as adding too much new complexity to service description & protocol for V3 - may consider in V4? consensus was to accept parameter as is. 3.2.7,8,9) all of these sections had minor changes agreed to on list. 3.2.10) Explain - new Info Categories - please send comments to Ray. 3.3) reworked segmentation algorithms & examples for clarity - Ray would like comments - positive or negative. 3.4) this section reduced & most of it moved to Sect 3.1.2 in front. 3.5) Concurrent Ops - completely rewritten - send any comments to Ray. 3.7) changed wording (at mtg) in 1st para @ top of P52. ASN.1 - P58 - decision @ mtg - AttributeSetId only needed to override main AttributeSetId at start of RPNQuery. P59 - minor changes. P60 - agreed to move ElementSpec to end of main ASN.1 - then use EXPORT to make accessible to Comp Specs in Appendix COMP. P60 - changed PreferredRecordSyntax to Object Identifier type. P65 - added IMPLICITs to requestPackage & resultPackage & corrected type to Object Identifier. Changed status under resultCommon to taskStatus. 4.4) do we need to change Conformance statement for V3? Especially due to use of Explain? folks need to think about this & get comments to Ray.. Appendix ATR - added attributes from D4 inadvertently le ft out of D7 (P85-6). Question: should we revise Larry Dixon's BIB-1 description & add as appendix? consensus was 'yes', & Ray will follow up with Larry. ******************************************************************* ITEM 17) Register of Implementors (Denenberg) Ray handed out updated version of 'Register of Implementors' - each implementor was asked to make any needed corrections & initial as correct & up-to-date. ******************************************************************* ITEM 19) Circulation/ILL subgroup (Hinnebusch) This subgroup re-convened at 6PM & I was not present as I had more pressing business & it was only required for those interested in this topic. Brad McLean led the mtg & agreed to take notes on any significant discussions &/or decisions. Since I was not in attendance & I am woefully ignorant in this area, I will defer to Brad to update the group on any matters of importance to the full ZIG list - thanks, Brad! END OF DAY - WEDNESDAY, JULY 7TH... THURSDAY MORNING - CIRCA 9AM: ----------------------------- ITEM 18) IETF Network Information Resource (NIR) (Needleman) Mark distributed latest version of NIR description of Z39.50 for the IETF working group & asked for comments/corrections - he has since posted the final copy to the list & forwarded it to the IETF chair. ******************************************************************* ITEM 16) OSI Implementors' Workshop (OIW) (Denenberg) Ray gave an overview of the OIW & their purpose: SIG for IR, ILL - started in '92 - mtg held in June of this year. Federal agencies want to work on federal regulations for stds. Interested parties: DOD, USGS, NISO, OIW, Ralph & Ray from ZIG. ******************************************************************* ITEM 20) Z39.50 implementation Study (Moen) Bill Moen of Syracuse presented an overview of a project he is proposing to undertake - under the proposal, he would gather information from current Z39.50 implementors & assemble a report (or set of reports) listing the services available from each operational Target, including what Z39 services are supported, available DB's & what attributes can be used to search them, what formats are available for retrieval records, & other types of data roughly corresponding to what would be available from Targets if Explain were fully operational. He could also keep other data such as what software (Origin & Target) is available publicly, info about new Origin/Target releases, etc. Bill was quite flexible as far as what data is kept, how it is gathered, how it is maintained, etc. There was discussion about the mechanics of the process, whether the data is gathered, maintained, & made accessible electronically, or whether some or all of these processes may be manual in the short term. Bill stated that the long-term plan is to automate this entire process & evolve it into an online 'server of servers' (which could be built electronically by searching & retrieving info records from each server's Explain DB), but that this is beyond the scope of the short term project he was proposing. He had spoken with Pat Harris (NISO President) & she endorsed his plan enthusiastically but said he needed to get the approval of the ZIG in order to proceed. There was a question about who would maintain this data for both short term & long term - Bill agreed to compile the data & keep it up to date on whatever periodic basis seemed appropriate to the ZIG - however, he was not sure who would maintain the data on a long term basis, if this study/survey were continued - someone suggested that NISO could gather & maintain it long term, but it was agreed to defer this issue. There was much discussion about the level of detail needed, what Info Categories from Explain would be useful, whether it would be possible to use AT&T Directory Services to store/maintain & provide access to this data. It was agreed to allow Bill to proceed in developing a plan to define this study/survey, using input from ZIG members for guidance. If members have any suggestions on the approach to this survey, please post to the list. ******************************************************************* ITEM 21) Reference Implementation Project (Tim Gauslin) Tim started by distribuing a couple of papers to the group - 1st a Project Description of the plan (formulated by a task force of government agencies - IWGDMGC, meeting as a Public Access Forum) to develop both a Profile & a Prototype 'Reference' Implementation for a 'Locator' service to be used (mainly) by government agencies. (Note: although these agencies may have special needs for a Locator Service which are somewhat less general than the 'global server of servers' concept kicked around at length in Z39.50, Archie, WAIS, & other groups, Tim said the goal was to develop a generalized Profile which could be used broadly across the info industry - not restricted to govt agencies). Once people had read the Proj Desc, there ensued a great deal of critical discussion focused on several major points: a) the idea of any specialized government or industry forum developing a profile (& even more particularly, a 'Reference Implementation') which would meet the needs of all or even a large subset of the total audience of Z39 users, seemed unrealistic at best, & impossible to many on the ZIG The ZIG was in agreement that the development of a Locator Profile is independent of, & shpould not be coupled with, the development of any type of specific implementation, & especially not something referred to as a 'reference' implementation. b) references in the doc to specific commercial vendors, such as Thinking Machines, WAIS Inc, etc. appeared to commercial members of the ZIG to provide unfair advantage to particular vendors' implementations, while hurting the adherents to the Profile by limiting their choices of vendors. It seemed far more reasonable to most that this project be separated into 2 totally separate portions - the 1st would simply develop the desired Profile, gathering input from ZIG members as well as others in the industry interested in implementing or using such a profile. This Profile would then be published (as an RFC, RFQ, etc.) & opened up to any vendors (either for profit or not for profit) wanting to build usable implementations. At this point, the 2nd portion would start - a number of competing (or in some cases complementary) implementations would be built - these would then be made available for testing & acceptance by users agreeing to use the profile. By using this approach, it is thought that a much richer,stronger set of implementations would develop, including related tools, gateways, & support software needed to make the server of servers (Locator) fly across the broad base of Z39 public & copmmercial services available at that time. The idea of producing a single 'reference' implementation seemed very premature to members - it was thought that a conformance suite of functions could be built over time, & that a 'reference' impl could grow out of the effort as it matured, but that to plan on this in advance weas unrealistic. On the last day of the ZIG mtg, Mark Hinnebusch produced & circulated a letter to be sent to Eliot Christian of the USGS, stating the criticisms of the Locator Project Description (see above). It was agreed to by the ZIG, finalized & sent by Mark, & as a result, Tim posted a revised Project Desc to the list this week & some comments have already been returned.. As a side note, Ray mentioned that the NIST OIW Library SIG is meeting on Aug 19th at USGS in Reston, VA - attendance at this mtg is restricted to federal agencies only. ******************************************************************* ITEM 22) Electronic Publishing of NISO Standards documents (Denenberg) Ray Denenberg & Mark Hinnebusch stated that the NISO board has reversed an earlier decision & decided not to allow free electronic distribution of NISO standards docs. The ZIG was in total agreement on denouncing the NISO decision - Mark wrote a letter to this effect, also stating that delays involved with hard-copy publication were also unacceptable in the spirit of getting the Z39.50 standard out to the widest audience in the most timely manner. The letter was circulated to & approved by the ZIG. ******************************************************************* ITEM 3) SCAN (Wibberley) Les expressed a need to have their Target return additional information describing each term in a term list, but he needs to be able to send different info for each database in which the term is found (i.e, at the attributeList, byDatabase level). Currently, the only provision for additional info is at the overall TermInfo level, which is not a fine enough breakdown. Les's proposal was accepted & Ray agreed to put a second otherTermInfo at the byDatabase level. Les also suggested that the entire occurrenceByAttributes structure be made optional, the4n someone else added that all of the subordinate structures should be optional - Ray will modify. ******************************************************************* ITEM 4) Extended Services public packages (Ryall) The chap from MDC (whatever his name is) handed out a doc describing a set of 6 ES Parameter Package types & their respective parameters, then did a high-level walk-thru of each of the ES 'Tasks', proposing that some or all of them be accepted by the ZIG for promotion to public OID status & included as part of Appendix EXP of V3. The point was made that we should try to standardize as many of the common-function ES Packages as possible; otherwise, if implementors went off & developed new private package types whenever they had as need for a new feature, we would have rapid proliferation of package types, many of them near duplicates of each other. It would be much better if implementors will share their functional needs with the ZIG before they develop a new package to see if others have similar needs - also, implementors who develop private packages could publicize them to the group so that others can use them & they can be considered as candidates for promotion to public package types. Ray agreed to work with other ES folks to finalize definition of ES package types targeted for V3 - other contributors are welcome to submit their private types to Ray as well. Peter will update the handout from the mtg, go thru the depressing task of downgrading it to ASCII, & re-post it to the list. ******************************************************************* ITEM 5) Document delivery requests (Stovel) Although there had already been some discussion about this on Wednesday - WRT to the use of ILL to accomplish this function (before the special Wed evening session on Z39.50/ILL, this was still on the agenda.. Lennie brought up the requirement but many others had the same need - it seemed there was a split between those who just had a simple need to deliver documents referenced by a Result Set (in which case an ES Export Task/Package could be used), & those who had a need to order & deliver docs not contained in a result set (& therefore not discovered via a search). The latter is the one we focused on, as it seemed to be a general need not addressed by any current Z39 service. It was suggested that we could define a new ES package type specifically to handle document delivery/order requests, but because of the complication of already having a standard (ILL) which is specificaly designed to do this function, the ZIG decided to take this topic to the list for further discussion.. ******************************************************************* ITEM 6) Explain (Denenberg) There was a short discussion of the current dfeinition of Info Categories & their related fields as defined in D7, & it was felt that there was still a good deal of work needed before these were solid - however, it was noted that experimentation & use of Explain in the real world would be the only viable way to flesh them out & find the holes in the structures (Bob noted that he is the only server who currently has implemented Explain, & this is not a very large sample set).. It was agreed that certain people be designated to work on new categories w/in Explain: Ralph & Mark will team up on Explain for Scan, Lennie will work on Sort, & Denis will focus on Extended Services.. Ray will stay involved with all of these subgroups to get consistency.. Start of Friday (I think) - 9am: ------------------------------- ITEM 7) ASCII Record Syntax (Wibberley) Although Les owned this agenda item, two separate proposals were handed out - one by Les & one by the tag team of John & Sean (I'm sorry, the tag team is the one that assigns Info-1 tags..). Although I didn't follow this discussion completely, it appeared that the 1st syntax needed was one that is totally unstructured, & Les' appeared to be closer to this than John's. The ZIG agreed as a group (during the discussion) on the characteristics of the unstructured text record syntax as the following: a) there will be no interactive specification of options (line length, terminating chars, page breaks, tabs, etc.) b) the line length will be part of the fixed definition of the syntax, & will be agreed to by the ZIG (72 proposed) c) the line terminating char will be an ASCII LF (X'0A') d) the text will use the GeneralString data type (which allows the sender to 'escape out' to a more specific string type if desired) I believe it was agreed that the structured text record syntax would be discussed & defined on the list (I may have been asleep then however..). ******************************************************************* ITEM 7.5) OPAC & Summary Records (Graubant-Cervona) Jeff requested that the syntax definitions for both the OPAC record and Summary record (agreed to w/in previous ZIG & ZIT discussions) be published & made available to anyone who wants to use them. Mark H. owns the current definitions & has them registered only on the private tree for FCLA - Mark agreed to post them to the list (again) & Ray said he would assign public OID's on the Z39.50 branch of the tree. ******************************************************************* ITEM 8) Bib-1 Attributes (Denenberg, Needleman) Margery passed out a list of attributes supported by Melvyl which are not currently supported by BIB-1 - there was some discussion of these, WRT whether or not we should incorporate the new attributes into BIB-1 or simply create another more specialized attr set. NOTE: I didn't take very good notes here (maybe someone else did & can expand on or correct me), but I think it was agreed that attrs of general use to folks (more than 1 server?) should be added to BIB-1, but others (such as the special attrs Sara mentioned) might be better in a secondary attr set (it was noted that this is not a problem in V3 as you can switch attr sets at the Term level. I'm not sure who has the ball here to follow up, if anyone.. In a separate discussion, someone posed a question about whether it would be useful to have a separate attr set that included all the MARC fields as attrs. It seemed of interest to some, & Joe Zeeman enthusiastically stepped up to enumerate these attrs & post them to the list - he has since done this (not fair to beat the minutes out, Joe) & is awaiting comments from the group - once it is approved by the ZIG, I assume it will be assigned an attr set OID (is this correct Ray?). ******************************************************************* ITEM 9) Bib-1 Diagnostics (Denenberg) It was noted that no work has been done on diagnostics since the last mtg & they are starting to be critical for some implementors. It was requested that everyone go thru their services & document all diagnostics which they expect they will need - send them to Ray, Lennie, & Ralph. It was agreed that any new diagnostics will be added to the list defined in BIB-1 (NOTE: the name of the diag syntax changed from BIB-1 to DIAG-1 - see below). A requirement was stated that a target needs to have a way to specify additional (free-form) information when it sends a diagnostic. There needs to be a way to distinguish this info from the info defined explicitly in the syntax definition (such as the database name in 'Database Unavailable' - BTW - this needs to allow for multiple database names). There followed a discussion about whether to add multiple addInfo fields, some structured & some not, which seemed unnecessarily complex to most folks. It was agreed that the simplest (& most versatile) way to structure the diag format is to make 'Condition' a CHOICE between an INTEGER, a VisibleString, & an OID (not an External?). It was also agreed that we would create a new diagnostic format type called DIAG-1 (& assign it a new OID), & leave the old BIB-1 for use only in Version 2. The details of the new DIAG-1 structure are to be worked out on the list.. ******************************************************************* ITEM 10) Access Control Formats (Denenberg) The group did a walkthru & discussion of the new access control formats defined in Appendix ACC - the DES & Copyright formats were copied from a document drafted by Eric Bivona & others several mtgs back. There was a new field added to des-1 to distinguish between challenge & response - des-1 & cop-1 were not challenged at the mtg. The Kerberos AC format krb-1 was proposed by Parvis & was not challenged. It was decided to modify the access-1 format proposed by Bob Waldstein slightly: infoValue & infoType were changed to IA5String (to allow only legal input characters), & tags were added to both fields. Sara stated a requirement to send a simple challenge for a clear text userID & password - it was agreed that Bob's format had no explicit way to ask for a simple userID &/or password. Les stated an additional requirement that the Target be able to request that a userID, old password, & new password be returned in the case where the user had asked to change his ID, or when a Target had a requirement that the user change his/her password on a periodic basis (e.g, every 60 days). Sara & Les agreed to work together & issue a proposal for another AC format to do this. Since then, Bob & John have proposed an alternative which enhances Bob's access-1 to include support for the ID/password challenge - it is still under discussion on the list as of this writing.. ******************************************************************* ITEM 10.5) Record Model Discussion ITEM 11) Composition Specifications (Denenberg) These 2 items were combined together into a single stimulating and mind-expanding discussion which I will not attempt to reconstruct here - in fact, it would probably require a white paper larger than the current Draft 7 of the std to record this highly interactive discussion. For those of us who couldn't keep up with the flow of e-mail traffic in the recent subgroup discussion on record syntaxes, it was a great opportunity to air our long-suppressed opinions that we hadn't been able to get edge-wise in the voluminous & fast-moving net interchange. At one point, this Friday pm session looked like 'dueling whiteboards across a football field' to the casual observer. All jest aside, however, much was accomplished (from this observer's vantage point) in terms of understanding the 'retrieval model' for requesting, formatting, subsetting, & receiving records in Z39.50. I'm really at a loss for words to communicate all the model clarifications that happened, so I'll just try to recreate the picture (which was the 1st 'record model' picture the group has totally agreed on so far, so I think it's worth capturing in some way) - I hope my feeble attempt is of some use to folks (both those who were & those who weren't at the mtg)... Starter Schema Schema syntax ----- -------- Schema ------ : ----- ES ----- | DB | | DB | ESN | | : | Abs |spec | Abs | Preferred rcd | --| | Record |----->| DB |oooooo| Rcd |---->| Rcd |------\ syntax | | |-->| | | Rcd | : | | | | (can | ----- --------| ------ : ----- -A--- change| |_________________:________________| repr. of| : elements)| Line of Z39.50 visibility ---->: V : ------------- : | Presentable | : | abstract | : | syntax rcd | : ------------- |Transfer | syntax | spec ^ | Hints about | | xfer syntax Appl | to be used Layer | | | | | - - - - - - - - - - - | | V | --------------- | | transmittable | Null, BER, | <----| record |<-----------' | | more specific --------------- If anyone needs explanations for this picture (which is hard to imagine after sitting thru 3 hours of discussion on it, but not everyone was there), talk to Cliff - & Sean - & Bob - & Les - & Mark - & Ray - & etc, etc. In other words, this was a group product & no one person can explain every detail - the importasnt thing is that we do have a good working consensus on the retrieval record model now.. To wrapup this agenda item, Ray proposed to change COMP-1 to ES-1, & attempt to consolidate the 4 current COMP specs into 1 or 2 generalized COMP specs - he will post these to the list when he starts work on Draft 8. Jeff Graubant-Cervona will also post his alternative scheme for specification of element specs to the list (that was the proposal on the board at the other end of the room). ******************************************************************* ITEM 11.5) Dynamic PreferredMessageSize for Segmentation (Dousti) Parvis (of CMU Project Mercury) that Z39 client developers must deal with a wide variety of different types of information (text, images, etc.) on a wide range of different servers. If an Origin wants to support Level 2 segmentation & it typically deals with text information the majority of the time, it has problems when it has to retrieve (present) image data from a database within the same association. There is no way to re-negotiate the segment (preferred message) size w/out closing & starting a new assoc, which seems quite inflexible. Parvis proposed that we add preferredMessageSize to the Present so that the Origin would be able to control the preferred size of the typical PDU, as well as the (aggregate) maximum message size & the maximum segment count. His proposal was accepted & Ray will add this as an optional parameter to the D8 - if included, it will override the preferredMessage Size specified in the Init, but only for the Present in which it's specified.. ******************************************************************* ITEM 12) Action Plan (Denenberg) Ray restated what he planned to do with Draft 7+ (minor corrections) vs. Drfaft 8 which he will produce in time to circulate for comment before the next mtg. Ray asked that people send him comments on the new Definitions section - changes, terms which don't need to be defined, terms which need to be added, etc. Les requested that Ray place a higher priority on producing the new ASN.1 for Draft 8 than on cleaning up minor errors in the current draft - Ray stated that he thought D7+ was important because he plans to make it available electronically for the 1st time - both in ASCII & WP5.1 versions (most likely via an FCLA FTP server). This was applauded, & Ray said he would have to think some more about whether we had enough definition on D8 changes to code the ASN.1 - especially WRT Comp Spec & ES Specs.. Margery said a top priority for her is to get new diagnostics defined & specified, including the new structure agreed to, fixes to the current diags, & the addition of new diags for scan, sort, & ES. She also suggested we do a walk-through before the next (& other) ZIG mtg. The format would be a half-day tutorial on a particularly hot & sticky ZIG topic ('the hot topic of the quarter'), presented by one of the recognized foremost experts on that topic. It was suggested that we make Explain the 1st guinea pig for this experiment, & have Bob doa walkthru at the Oct mtg in Ottawa (Bob graciously consented after his arm was graciously twisted into knots a few times)... ******************************************************************* Implementation Issues: --------------------- ITEM 13) ASN.1 Coding Guidelines (Wibberley) Les re-distributed a paper written & handed out by John Kunze several mtgs back - Les had raised the issue on the list just before the mtg so there wasn't time for anyone to respond yet. There was some discussion which recalled some of the objections raised when it was 1st proposed - Bob W. reiterated that doing lots of indirect definition statements to achieve to miniize the number of duplicate inline definitions sometimes causes more difficulty with readability, & also complicates the structure fabrication for people not using ASN.1 compilers who are having to trace through the ASN.1 to find out how to build their message structures. Les pojnted out in his memo that by not using these guidelines, it causes more work for developers writing code which interfaces to the Z39 request/response structures produced by a compiler - an example was that when you use CHOICE or SEQUENCE in the middle of a structure, the compiler does dynamic definition generation, which creates labels that change every time there is any change in the request structure. This creates alot of extra work when moving from one version of the standard to the next, & even causes changes in areas that didn't changed functionally. It was decided that this discussion should be taken to the list since there were many differet views & time was running out for the mtg. ******************************************************************* ITEM 14) ZIG/ZIT agreements (Needleman) Mark handed out copies of the agreements he has documented from previous ZIG & ZIT mtgs - he ask4ed that people red them & send any comments back to the list. ******************************************************************* ITEM 15) Handling Encoding and Protocol Errors (Orlik) I had already left for my plane when this agenda item was reached - apparently just about everyone had also - Ralph sent me an excellent note to summarize what the agenda was supposed to address, & it was so good I thought I'd just include it here - obviously this discussion needs to be taken back to the list, or deferred 'til the next mtg.. Ralph (Orlik) says: We reached agenda item no. 15 about 4:00 on the 9th of July, when people were ready to leave St. Louis. I added the item at Ray's urging after we received incorrectly encoded Search and Present Request PDUs. Larry raised the question on the list and we found out that others were doing things from Aborting the connection to ignoring errors( when they could recognize them and there was a reasonable default to take) to sending back diagnostics with additional information( when the Diagnostic was in the normal response to the problem, i.e. Search and Present Responses). The standard says little about what to do for protocol errors. It assumes that PDUs are correctly encoded, provides no diagnostics to address encoding problems( in those PDUs where diagnostics are present), and leaves the state tables undefined. Encoding errors are one type of protocol error that can sometimes be corrected. Some said that a protocol error is a protocol error and Abort is the only response possible. Whether you can recover from one at all requires that the decoding software tell you what the error is and not quit there. The Presentation layer we had with the IBM product would not let us receive a PDU with encoding errors, while the UC-DLA code we have now does keep on going with the possible loss of data (which data, we don't know). I think that there was agreement that in V3 the CLOSE PDU would be the correct response to an encoding error, along with a reason for closing. In V2, one is limited to using User information or the additional information in a non-surrogate diagnostic. Other Information( V3 and V2, too?) might be used with any PDU, including the CLOSE, by those able and willing to provide help to Z39.50 origins or targets which send faulty PDUs. ******************************************************************* ITEM 15.5) OSI Application Context OID (Ryall - in absentia) The reason I asked for this agenda item was to request an Application Context OID for an Application Entity which would permit the running of multiple Z-Associations over a single A-Association. Unfortunately, I had to catch a plane, but Ray said I could just send him a request thru the mail anyway - the only reason I mention this here is that I wanted to let other folks know in case they need to use this Context in the future. ITEM ?) Discussion of alternative Data Types for Search Terms This was not an agenda item & I didn't when it was discussed, but there was a short discussion (possibly during the Attribute Set item, about supporting other data types in the Search Term field, & how the Origin would designate the data type of the Term value, versus the data type of the fields in the databases being searched. It was noted that there is a need to treat a term as a data type other than text in some cases - examples were: numerics, raster/vector graphic components/tiles, & 3D chemical structures. Ray suggested (as a proposal) that we allow a data type other than OCTET STRING for each Term - possibly a CHOICE of OCTET STRING, INTEGER, & EXTERNAL? (I don't know if I accurately recorded this, Ray - better run integrity checking on it)... Hope to see you all in October...Th-th-th-th-th-at's all folks!! thanks in advance for any & all corrections - your humble & fat-fingered note-taker...Peter