Date: Wed, 27 Jul 1994 09:09:55 -700 (PST)
From: Mitra <mitra@pandora.sf.ca.us>
Subject: Re: Version 5 of URL draft
To: "Mark P. McCahill" <mpm@boombox.micro.umn.edu>
In-Reply-To: <199407271450.JAA03356@boombox.micro.umn.edu>
Message-Id: <Pine.3.89.9407270948.A17151-0100000@pandora.sf.ca.us>
This looks fine except .... we havent defined a "search" this could be
done simply by adding "(gophertype=7)" at some point so that it is
unambiguous how to determine when to send the search string.
- mitra
On Wed, 27 Jul 1994, Mark P. McCahill wrote:
> In message <94Jul26.133457pdt.2760@golden.parc.xerox.com> Larry Masinter writes:
> > ...[deleted text...]
> > ***********************
> > Open issue:
> >
> > Mitra has pointed out that there is an ambiguity of how a gopher: URL
> > should be interpreted in the case where there is a gopher+ string and
> > there is not a search: should the client send to the server one or two
> > tabs, and on what basis should it determine this?
> >
>
> I'm really sorry I couldn't make it to what Peter Deutsch described as
> "swinging" Toronto (I guess Peter would know), but (like Peter) I had to
> stay home and work this time :-(.
>
> Anyway, down to business.
>
> If the Gopher+ URL doesn't refer to a search, the client should send
> the server a single tab, and if it does refer to a Gopher+ search, the
> client gets to send two tabs.
>
> At the end of this message is a slightly revised version of the gopher
> section that should make this more clear.
>
> > Does it need to
> > look at the gophertype to determine whether this URL denotes a search?
> >
>
> Yes. You need to parse the URL before you can send the right
> thing to a gopher server. A base gopher client sends this to
> a gopher server:
>
> selector string [<tab> search string]
>
> So in the original gopher protocol, <tab> is used to seperate the search
> terms from the gopher selector string. The design goal for Gopher+ was
> to be upward compatible with the original gopher. So... the gopher+ info
> is seperated from the original gopher info by a tab:
>
> selector string [<tab> search string] [<tab> gopher+ info]
>
> So, there are two cases. In the case where a gopher+ item is not a search,
> the client sends this to the server:
>
> selector string <tab> gopher+ info
>
> In the case where a gopher+ item is a search, the client send this to the
> server:
>
> selector string <tab> search string <tab> gopher+ info
>
>
> See below for a slightly revised gopher section making this more explicit.
>
>
> -----------------------------------------------------------------------
>
> 3.4.3 URL syntax for Gopher+ items
>
> URLs for Gopher+ items are have a second encoded tab and a
> gopher+ string. Note for Gopher+ URLs, the %09<search> string must
> be supplied, although the <search> element may be an empty string.
>
> The <gopher+_string> is used to represent information required for
> retrieval of the Gopher+ item. Gopher+ items may have alternate
> views, arbitrary sets of attributes, and may have electronic forms
> associated with them.
>
> When a gopher client retrieves an item from a Gopher+ server, the
> client send Gopher+ commands to the gopher server by appending
> a <tab> and the gopher+ commands after the gopher selector (and the
> <tab> and search string in the case of a gopher search item). If a
> Gopher+ URL does not refer to a Gopher search type, the Gopher
> client sends to the server the gopher selector string, followed by a
> tab, followed by the gopher+ commands. If the Gopher+ URL refers to
> a Gopher search type, the client sends to the gopher server the gopher
> selector string, followed by a tab, followed the search string,
> followed by a tab, followed by the gopher+ commands.
>
> ----------------------------------------------------------------
>
>
>
>
> Mark P. McCahill gopherspace engineer
> mpm@boombox.micro.umn.edu University of Minnesota
> 612 625 1300 612 625 6817 (fax)
>
>
>
>