# Re: Z39.50 and URI

wald@library.mt.att.com
Sat, 3 Sep 94 22:35:12 EDT

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Michael A. Dolan: "Re: [John.Ockerbloom@gs1.sp.cs.cmu.edu: Re: FTP handling suggestion]"
- Previous message: Simon E Spero: "Re: Z39.50 and URI"
- Maybe in reply to: Dirk Herr-Hoyman: "Z39.50 and URI"

    Date: Sat, 3 Sep 94 22:35:12 EDT

    Message-Id: <9409040235.AA00548@ln4>

    From: wald@library.mt.att.com

    To: Marc VanHeyningen <mvanheyn@cs.indiana.edu>,

    Subject: Re: Z39.50 and URI

>From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
>
>> Guess I am saying that the Z39.50 protocol does nothing to make it
>>slow, EXCEPT having to do an init, so a minimum of 2 round trips.
>>Plus our (Z39.50 IR type environments) are by definition where
>>individual record fetches from large corpuses had better be fast.
>
>Some concern, but I wouldn't call it major, about init issues. It has
>other implications; Z39.50 presumably could not function via T/TCP,
>while presumably whois++ could, for instance. IMHO quite important is
>how much code/time/effort it takes on the client end to understand and
>implement the protocol, though.

NOte I am entering the middle of a discussion - my apologies where I am out
of context; note I am not subscribed to URI list. But some comment on this:
- I don't know what T/TCP is. I have run Z39.50 over Datakit and just
plain modems (not SLIP). I don't see why any clean 8 bit protocol
would have trouble, but am out of my league at this level.

- > IMHO quite important is how much code/time/effort it takes on the client
Mixed emotions here, with 2 comments. FIrst (and I think real important
in todays world) is a protocol that can expand cleanly and interoperably
to meet all requirements imposed on the protocol. Sure simplicity is
important, but so is clean/clear extensibility.
Z39.50 has a problem, it appears immense and confusing. Its core
is not that bad. Yes ASN.1 is there -- but actually after my first
moans I now am sold on it as a binary package description language.
So for Z39.50 (client end) to do what I think you want you need:
- a simple package for the core of BER/ASN.1 needed.
- encoding/decoding of init (this is nearly trite)
- a trivial search encoder. Note in my base implementation I do not use
or need most of the attribute stuff that allow Z39.50
complete index/search control by the client.
- a returned record cracker (in search response for speed). NOte
if you must Z39.50 allows you to define your own record. So this
is actually as complicated as your applications needs.

Thats it; but once you have this it is easy to start adding things like:
- restrict to north american responses.
- restrict to free sites.
- I want only GIF, not TIFF
- THe server must give French.
- this search is cyrillic; or spatial; or numeric rang.
Or whatever you want. THis is more complicated Z39.50 of course; but heh
if you ask more complicated information requests thats expected.

SOrry I do not have time to join the URI discussion fully - wish I
did but have even been ignoring Z39.50 recently due to work!! -)
Bob Waldstein wald@library.att.com

- Next message: Michael A. Dolan: "Re: [John.Ockerbloom@gs1.sp.cs.cmu.edu: Re: FTP handling suggestion]"
- Previous message: Simon E Spero: "Re: Z39.50 and URI"
- Maybe in reply to: Dirk Herr-Hoyman: "Z39.50 and URI"