# Re: URLs and Z39.50

Roy T. Fielding (fielding@avron.ICS.UCI.EDU)
Tue, 29 Nov 1994 23:20:15 -0800

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Michael Mealling: "lack of a URC spec paper this go around..."
- Previous message: Karen R. Sollins: "going too far?"
- In reply to: Larry Masinter: "Re: URLs and Z39.50"

    To: uri@bunyip.com

    Subject: Re: URLs and Z39.50

    In-Reply-To: Your message of "Tue, 29 Nov 1994 13:52:38 PST."

                 <94Nov29.135253pst.2760@golden.parc.xerox.com>

    Date: Tue, 29 Nov 1994 23:20:15 -0800

    From: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>

    Message-Id:  <9411292320.aa02766@paris.ics.uci.edu>

I wrote:
>> In my opinion, this is not an option. A URL is a resource locator, not
>> a protocol. Any information beyond that necessary to identify the location
>> and access scheme for the resource should not appear in the URL. Instead,
>> such information should be determined dynamically by the client state,
>> client and server configuration, and whatever negotiation is supported
>> by the protocol.

and Larry Masinter replied:

> I think we've taken a pragmatic rather than purist approach to the
> question of what should and shouldn't be in URLs, and we could do so
> for z39.50, too. If 'recreating the server z39.50 environment' is
> necessary to locate the information, then the information needed
> should be there.

Yes, I agree, though I see no difference between the pragmatic and
purist approaches to specifying a not-yet-implemented URL -- the most
pragmatic approach is to avoid impurities now rather than having to
deal with them later. Had someone proposed the existing gopher URL
today (sans implementation), I would have screamed.

What is needed is a precise determination of what is necessary to locate
resources in z39.50. I include as resources both system resources
(what seems to be intended by the session url) and documents (what seems
to be intended by the retrieval url). Once "what is necessary" has been
determined, it can be mapped to an appropriate URL syntax. I think that
is what John and the z39.50 implementors group have done in their draft,
but I can't be sure until I find the time to look up the definitions
for the parts I don't understand and possibly do some testing (or somebody
does it for me). That's not likely to happen until after San Jose.

One thing I do know is that it would be much *much* better to use
the generic parameter syntax of

*( ";" field [ "=" value ] )

than to use the url-encoded form data syntax of

"?" [ field [ "=" value ] *[ "&" field [ "=" value ] ] ]

The latter syntax was a kluge to get HTML FORMs to work with older HTTP
servers. It is now deprecated within WWW. Among its faults:

a) They can't be reliably embedded in SGML documents, because "&"
is a reserved character within most attributes (e.g. anchor hrefs).

b) URLs get so long that they break older systems' max url string length
and clutter up the browser's history file.

The latter problem also applies to ;params if they are not restricted to
a reasonable set.

On a slightly related subject, is there a public z39.50 V3 server available
which will allow protocol testing?

......Roy Fielding ICS Grad Student, University of California, Irvine USA
<fielding@ics.uci.edu>
<URL:http://www.ics.uci.edu/dir/grad/Software/fielding>

- Next message: Michael Mealling: "lack of a URC spec paper this go around..."
- Previous message: Karen R. Sollins: "going too far?"
- In reply to: Larry Masinter: "Re: URLs and Z39.50"