# Re: Final edits - summary of outstanding points.

Dirk Herr-Hoyman (hoymand@joe.uwex.edu)
Fri, 22 Oct 93 11:36:40 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Comserve/CIOS Staff Office: "Announcements of general interest within the Comserve community"
- Previous message: Dirk Herr-Hoyman: "Re: New URM paper with additions!"
- Maybe in reply to: Mitra: "Final edits - summary of outstanding points."
- Next in thread: Rich Wiggins: "Re: Final edits - summary of outstanding points."
- Reply: Rich Wiggins: "Re: Final edits - summary of outstanding points."

    Date: Fri, 22 Oct 93 11:36:40 -0500

    Message-Id: <9310221636.AA16998@joe.uwex.edu>

    To: uri@bunyip.com

    From: hoymand@joe.uwex.edu (Dirk Herr-Hoyman)

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

Mitra said:
>I havent thought through the Type-field/relative path issue yet, the question
>with Gopher Type fields is not whether type information is usefull for
>retrieval. The group had that discussion and decided that types belong in
>the URC or whatever. The trouble is, we've got the type there in the
>middle of the Gopher URL.
>
Tim B-L said:
>>16) Should the type field be retained in the Gopher0 URI, I think
>its
>>redundant, I think Tim believes its needed?
>
> Yes. It is part of the gopher link and to say that
> you can do a retrieval without knowing what you are
> getting back is in principle true but quite useless!
>

This is a subtle point about the Gopher protocol. There are really two
"types" involved here. There is the Gopher "type", which gives info so the
client can display something (icon, character) on the menu and there is a
retrieval "type", which is the first character of the selector string.

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.

But, the Gopher "type" is not necessary. 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?

- Next message: Comserve/CIOS Staff Office: "Announcements of general interest within the Comserve community"
- Previous message: Dirk Herr-Hoyman: "Re: New URM paper with additions!"
- Maybe in reply to: Mitra: "Final edits - summary of outstanding points."
- Next in thread: Rich Wiggins: "Re: Final edits - summary of outstanding points."
- Reply: Rich Wiggins: "Re: Final edits - summary of outstanding points."