Exploring Z39.50 URLs: Current Uses and Future Potential

1. Z39.50 URLs December 2000 ZIG

2. Chair: Kevin Gamiel Abstract: How are Z39.50 URLs (Z39.50s and Z39.50r) being used? What purposes should a Z39.50 url serve? Are these existing definitions serving these purposes? Should they be revised? Should a new Z39.50 url be defined? And if so, should it replace or compliment the existing definitions?

3. Plan • Introductory overview, background, etc. • "Current Z39.50 URL". Describe the current Z39.50 URL, it's structure, what can be done with it. • "Current uses". The ways that ZURLs are currently used in applications. • "Future". Desired use of a Z39.50 URL. Generalizing the URL structure beyond a Z39.50 scope.

4. Expectations • Explore how z-urls are currently used. • Explore the potential utility of a newly-defined Z39.50 url -- what would people like to use a Z39.50 url for, if they could? • Based on above, determine if a new definition is needed.

5. Expectations (continued) • If so, set in motion a process to determine the requirements, develop a definition, and to reach agreement. Stress "set in motion the process"; we're not planning to determine requirement, develop a definition and reach agreement in this session, just to set the process in motion.

6. Z39.50 URLs History and Overview December 2000 ZIG

7. September 1994ZIG Meeting at CNIDRMinutes from Denise Troll • session and fetch URL • Z39.50://host[:port][/database][/docID][/...] • When users click on this URL, it will open a Z39.50 client ("helperapplication"), point to the existing service, construct a RPN query, and return a result set with one or more items. The Z39.50 client will theneither convert the items to HTML for display in Mosaic or open the Z39.50 client to the user. The Z39.50 client is responsible for determining whether or not to open to the user. [Brad McLean]

8. Potential problems cited for this proposal were: • DocIDs change over time. The ID should be a logical ID. [Ryan Troll] • What about the result set name? • Is this a transient or persistent result set [Ray Denenberg]? • Three unresolved issues remain [Brad McLean]: • Element set names • Should we restrict this to retrieving a single document or enable retrieving multiple documents (with the client deciding what to do if there are multiple items)? • Access control (user ID and password).

9. Do we want 2 URLS, one to fetch and close, the other to be interactive, or 1 URL (that launches a helper to determine whether to fetch and close or run interactive)? • Mark Hinnebusch framed the question, but many ZIG members participated in the lengthy debate, in the midst of which Ray Denenberg pointed out that the URL must include the record syntax. The debate was tedious, but well done, with ZIG members switching camps throughout.

10. Leaders (rhetors) eventually arose for the two camps and final arguments were given. Ralph LeVan argued for 2 URLs. Denis Lynch argued for 1 URL. Mark Hinnebusch somehow divined concensus and the shot was called: there will be 2 URLs: • Search URL: • Z39.50s://host[:port][/database[+database...] [/term[&ESN=elementset][&RS=recordsyntax[+recordsyntax]]]] • Retrieve URL: • Z39.50r://host[:port][/database[+database...] [/term[&ESN=elementset][&RS=recordsyntax[+recordsyntax]]]]

11. Database name is required. Any missing components default to the client's choice. If more than one record syntax is provided, the first one in the sequence is preferred. If the client cannot handle the preferred syntax, it my choose among the others. • John Kunze was commissioned to take our URL proposal to the IETF URL group.

12. 1996 -- RFC 2056:Uniform Resource Locators for Z39.50 • The Z39.50 Session URL • The Z39.50 Retrieval URL

13. z39.50url = zscheme "://" host [":" port] ["/" [database *["+" database] ["?" docid]] [";esn=" elementset] [";rs=" recordsyntax *[ "+” recordsyntax]]] zscheme = "z39.50r" | "z39.50s” “Future extensions to these URLs will be of the form [;keyword=value].”

14. Z39.50 Session URL • informally described as providing the mechanism to switch the user to a z39.50 client application. • Host is required. • Port is optional, and defaults to 210. • All other parameters are optional. • Z39.50 client starts a session to the specified host/port (need not explicitly start a session, may instead utilize an already open session to the same host/port).

15. A database must be included if docid is included. • If docid is included, the client will perform the specified search • If docid is not included, and other parameters (besides host/port) are specified, the client may use those parameters as "hints". • Various clients may choose to treat them as requirements, or as preferences, or ignore them.

16. In any case (whether a search is Performed or not), the client leaves the Z39.50 session open for the user, to do retrievals, new searches, etc. (This is the main distinction from the Retrieval URL which leaves it up to the client whether or not to keep the Z39.50 session open.)

17. The Z39.50 Retrieval URL • Intended to allow a Z39.50 session to be used as a transparent transfer mechanism to retrieve a specific information object. • A Z39.50 client uses information in the URL to formulate a Search Request. The server's Search Response indicates how many records match the Request.

18. If number of matching records not equal one: • the retrieval is considered unsuccessful, and the client application's behavior is not defined. • If number of matching records equals one • the server may have included the desired record in the Search Response. If not, the client requests transmission of the record with a Present Request. • After the client has received the specified record it may close the Z39.50 session immediately, or keep it open for subsequent retrievals.

19. Host required. • Port optional, default 210. • Database required. • The meaning of a retrieval URL with no docid is undefined. • docid placed into a type-1 query, as the single term, in the general format (tag 45) • Bib-1 attribute set • Use attribute docid • structure attribute of URx • The docid string is server-defined and completely opaque to the client.

20. Questions • Are there other current uses we didn't list? • Is current usage so minimal that we can simply "start over"? Is anyone actually using ZURLs, or is this all an academic exercise? • If we generalize it, is this a job for the ZIG? Or IETF, W3C, etc? • How transient is a URL? • Should we have result set offsets in a URL? • How do we address a specific result record for a system without the docID concept?

21. Questions • Can we stringify the Z39.50 query structure in a manner suitable for including in a URL, making it simpler for the lay-person to construct one? • What about the content of the response to a Z39.50 URL? Although it may not be entirely in the context of a Z39.50 URL definition (implementation rather than definition) Some discussion about this may be appro-priate. For example consider an implementation that transforms everything to XML for transmission to the client process, convenient for post-processing of results, but the structure of the XML document pro-duced may not be appropriate for all user classes.

22. Questions • Is it possible to provide a stateful implementation of Z39.50 URLs without the need for alternative Z39.50 protocol identifiers?