# Re: Final edits - summary of outstanding points.

Mark P. McCahill (mpm@boombox.micro.umn.edu)
Fri, 22 Oct 93 16:38:49 CDT

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Fred Swartz: "URN -- case issues"
- Previous message: Lars-Gunnar Olsson: "Re: <> One Last Time"
- Maybe in reply to: Mitra: "Final edits - summary of outstanding points."
- Next in thread: Dirk Herr-Hoyman: "Re: Final edits - summary of outstanding points."

    Date: Fri, 22 Oct 93 16:38:49 CDT

    Message-Id: <9310222138.AA18812@boombox.micro.umn.edu>

    From: "Mark P. McCahill" <mpm@boombox.micro.umn.edu>

    To: hoymand@joe.uwex.edu, uri@bunyip.com

    Subject: Re: Final edits - summary of outstanding points.

In message <9310221636.AA16998@joe.uwex.edu> Dirk Herr-Hoyman writes:
>
> This is a subtle point about the Gopher protocol. There are really two
> "types" involved here.

not really.

> There is the Gopher "type", which gives info so the
> client can display something (icon, character) on the menu

This is correct.

> and there is a
> retrieval "type", which is the first character of the selector string.
>

This is not correct. The selector string is opaque. Woe unto the client that
interprets the selector string. It turns out that for its internal convenience
and efficientcy, our Unix server does code some information into the selector
string, but other gopher server on other platforms do not do this. For the
server's convenience in some cases we have been coding information other than
a one character "type" into the first part of the selector string on the unix
platform. Servers running on other platforms are free to encode whatever they
like in whatever form they like into the selector string. So... the selector
string is an opaque entity. Do not interpret it.

> The URL spec under consideration has both in it. What adding the Gopher
> "type" buys you more info for a client display, just like what Gopher does.
> Note that in Gopher, this is really 2 fetches (one for the menu, the
> second with the selector), so this URL in a sense lets you have info that
> would have taken 2 fetches.
>

I don't understand what you just said.

> But, the Gopher "type" is not necessary.

The gopher type IS necessary. You cannot depend on interpreting the
selector string.

> The client will be able to look
> at the selector string for Gopher and know whether what's coming is a menu
> or not (which is necessary). While we might consider the Gopher menu
> return just another type consideration, you really can't work with Gopher
> if you can't distinguish between menus and documents. Distinguishing
> document types, is a separate matter that spans all protocols.
>
> All in all, I'd have to say that the Gopher "type" is just meta-info and as
> such should be in the UR[C|M].
>
> Is it correct to presume that changing this will break existing WWW
> clients? Are WWW clients using this information to know, for example,
> that the item is a Mac BinHexed file and then preceed to unbinhex it?
>

I think the clients had better be looking at the type to know whether to
interpret the stuff coming back as a document, or directory, or search engine.
Once you accept this, you might as well go hole hog and accept the idea that
the client would like to know if the document is text, image, video, sound,
etc.

See ya'll in Houston. :-)

Mark P. McCahill

Gopherspace Engineer
University of Minnesota Computer & Information Services
room 125 Shepherd Labs mpm@boombox.micro.umn.edu
100 Union Street SE 612 625 1300 (voice)
Mpls., MN 55455 612 625 6817 (fax)

- Next message: Fred Swartz: "URN -- case issues"
- Previous message: Lars-Gunnar Olsson: "Re: <> One Last Time"
- Maybe in reply to: Mitra: "Final edits - summary of outstanding points."
- Next in thread: Dirk Herr-Hoyman: "Re: Final edits - summary of outstanding points."