Message-Id: <9310222144.AA20041@mocha.bunyip.com>
Date: Fri, 22 Oct 93 17:22:06 EDT
From: Rich Wiggins <WIGGINS@msu.edu>
Subject: Re: Final edits - summary of outstanding points.
To: Dirk Herr-Hoyman <hoymand@joe.uwex.edu>, uri@bunyip.com
In-Reply-To: Your message of Fri, 22 Oct 93 11:36:40 -0500
>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).
Whoa, I lost you there. The Gopher RFC explicitly states that the
selector string is opaque to the client. As a matter of practice
it is often the case that the selector consists of the path name
for the document preceded by the type character, but if it's done
that way, that's the server's business, not to be relied upon by
the client. There is no requirement in the Gopher protocol that
what you call the "retrieval type" be present in a selector string,
and there are Gopher servers that do not offer that as the leading
character for their selectors. (Not to mention gateways such as
go4gw which expect specific multi-character strings like "nntp".)
/Rich Wiggins, Gopher Coordinator, Michigan State U