Date: Wed, 24 Aug 94 07:18:00 PDT
From: Fisher Mark <FisherM@is3.indy.tce.com>
Subject: Re: Z39.50 and URLs
To: "'URI'" <uri@bunyip.com>
Message-Id: <2E5B68A7@MSMAIL.INDY.TCE.COM>
Dirk Herr-Hoyman said this:
> 1) Connectionless vs. connection-oriented. The work so far in URI has a
> connectionless orientation. Z39.50, on the other hand, is connection
> oriented. It is meant to be run in a session, with results from a request
> being used later. This doesn't map very well to a URL, and is a large
> reason why there is no Z39.50 URL yet.
Although the HTTP model is a stateless, connectionless, request/response
system, it is not the only model worth pursuing. A URL is a Uniform
Resource Locator -- there is nothing implicit in the notion of URLs that
says anything about whether a connectionless or connection-oriented
transport is used. The "telnet:" scheme is a case in point.
Because URLs arose from Tim Berners-Lee's WWW work, there has been a bias
towards URLs representing a virtual file to be retrieved. ("Virtual" in the
sense of a search query returning HTML just as if there was a file with that
information.) Just as HTML forms are used to generate fairly complex
virtual files, you could have a Z39.50 server return a session ID for use in
retrieving further parts of the original virtual file, as mentioned below by
Stuart Weibel of OCLC in <199408232053.QAA00937@ws02-00.rsch.oclc.org>:
>OCLC and CNIDR, to name at least two, are implementing Z39.50 gateways
>that will be accessible via WWW. Both approachs involve maintaining
>session information on the server side (timed out after an arbitrary
>interval) and to embed a token in the URL that contains a session ID
>used by the server to sort out the URL's appropriately.
>
>This means, of course, that the resulting URL is not persistant... It
>may pertain to a result set, for example, that will change in a
>dynamic database (a feature, not a bug).
>
>If their is a desire to see the development of a standard URL for Z39
>access, we would be pleased to help formulate one based on our
>experiences, and I'm sure CNIDR folks would be happy to bring their
>experiences to bear as well.
======================================================================
Mark Fisher Thomson Consumer Electronics
fisherm@indy.tce.com Indianapolis, IN
"Just as you should not underestimate the bandwidth of a station wagon
traveling 65 mph filled with 8mm tapes, you should not overestimate
the bandwidth of FTP by mail."