Date: Tue, 8 Mar 94 08:52:42 -0600
Message-Id: <9403081452.AA26689@joe.uwex.edu>
To: "Mark P. McCahill" <mpm@boombox.micro.umn.edu>, timbl@www3.cern.ch
From: hoymand@joe.uwex.edu (Dirk Herr-Hoyman)
Subject: Re: gopher+ support in the URL draft.
At 7:17 PM 3/7/94 -0600, Mark P. McCahill wrote:
>With a minor change to the syntax of the current gopher URL, we can have both
>plain old gopher and gopher+ in the same URL and have a nice regular syntax.
>The improved syntax is basically the current gopher URL syntax, but uses an
>encoded <tab> character as a seperator rather than the <?> character. Using
><tab> as a seperator is convenient because <tab> cannot occur in gopher
>selector strings. The only time the <?> is used in the current gopher selector
>is when the URL points to a gopher search engine and is passing the search
>engine a search string (tth of words for which to search)... the virtue of
>having a regular syntax and using a seperator character that cannor occur in
>gopher selector strings should to be obvious.
>The format of a gopher URL is:
>
Mark, I'm not following why you are changing from using ? as the seperator
for searches to tab. It seems that if you let %09 be the gopher+ "flag"
you could still use ? for searches. Perhaps I'm just being dense here and
you can educate me. I've listed some counter examples that appear to work
for me.
>An example of a URL pointing to a gopher type 7 item (a search engine)
>where the string foobar is to be submitted to the search engine is:
>
> gopher://host [port]/7a_gopher_selector%09foobar
>
gopher://host [port]/7a_gopher_selector?foobar
If this were a 7+ search, then
gopher://host [port]/7a_gopher_selector%09?foobar
Which looks to both preserve the existing search syntax and allow for gopher+.
I would prefer to see an orthagonal treatment of searches (and anything
else) within the not-so-opaque selector string. Are we going to allow for
a separate evolution of these "added" parts of the selector strings by each
service or are we going to try and do something uniform? I am seeing
selectors proposed that will have to be parsed, rather than merely passed
directly to the server, which leads me to wonder whether we shouldn't think
about (* oh, no *) a STRUCTURE.
Mark, I'd also like to see something about how attributes are to be
handled, even if it's brief. For example,
Returns the attributes. This is very different than
which actually fetches the item. The implecation here (and for ASK+
blocks) is that what happens cannot be determined merely by looking at the
single character gtype, you must know whether it's gopher+ or not.