Date: Wed, 23 Mar 94 11:30:19 CST
Message-Id: <9403231730.AA07841@boombox.micro.umn.edu>
From: "Mark P. McCahill" <mpm@boombox.micro.umn.edu>
To: timbl@www0.cern.ch, uri@bunyip.com
Subject: Re: how to make progress on the URL document
In message <9403231537.AA14169@ptpc00.cern.ch> writes:
> OK, I had marked it up and linked it in too, as a draft
> I'll make it the definitive if everyone is OK with it. I just
> wondered if it had changed. I would like to make
> the following changes:
>
> 1. Use "?" back as search delimitera s it was
> As it is the
> last thing in the URL it doesn't screw anything
> up, it is easy to implement, and "?" is a reserved
> character anyway.
Since it looks like you are revisiting the same old arguments again, I
guess I will (again) bring up the points I have made repeatedly on this
mailing list.
1.) It is silly to impose the same syntax on all URLs, and there is no
functional requirement for this. URLs have a functional requirement
to specify an access method and an opaque parameter package for
use by that access method. Period. There is general agreement
on this.
2.) It happens that gopher already has reserved a character (tab) as
a seperator, so "?" as a seperator was a poor choice in the first place.
3.) The ? convention for al URLs that do searches will either break or
require re-written clients to deal with searches of relational databases.
Mandating "?" for all searches in all clients is a very bad idea.
Dirk Herr-Hoyman pointed out that the HTML+ URLs (which incidentally
are not defined in the current document) use the convention
?name.x=2&name.y=29
for a URL used to fill out forms and this might be a candidate for
specifying searches of databases with fields. Unfortunately, for this
to work, the client has to know that after the "?" seperator, a "="
seperates field names from field values and these pairs are seperated
with "&"... so the client still has to know the details of the access
method to interpret the information following the "?" in the URL...
mandating "?" as a search seperator doesn't gain you anything.
Again, this was discussed at length on this mailing list, and the
advocate of the "?" seperator left the discussion at least half convinced
that mandating "?" as a seperator for all URLs is not a good thing, given
that the client would still need to know the details of the access method.
Other advocates of requiring "?" as a seperator for all URLs were not
forthcoming, and the consensus is that URLs are access methods
with parameter packages that are specific to the access method.
Tim, I wouldn't presume to impose Gopher-format parameter packages on
HTML/HTML+ or Z39.50 URLs since you ought to be free to define a URL that
works well with your protocol. By the same token, you should not be
mandating the format of the parameter package for the Gopher/Gopher+
protocol...
> Reasons as before. Also,
> don't want to change it now. It'll break existing
> URLs and software.
>
The point has been made again and again that you can't argue that because
there is an installed base, we can't fix things. Moreover, existing URLs and
software can be distinguished from the new URLs since the new ones have the
URL wrapper around them.
> 2. In a URL, if a "/" does not imply a hierarchy, it
> should be escaped. (This just affects gopher servers
> whose files contain "/" but aren't directory
> delimiters, like Mac servers). If you want the
> string to be 100% opaque, just specify that
> "/" is escaped.
>
Once again, a URL consists of an access method and an opaque parameter
package for use by that access method. To know how to interpret the
opaque parameter package, the client writer needs to read the
section of the URL document that tells them how. If the access method
says that there is no heirarchy to be assumed, and you ignore this, then
you do so at your own risk.
We shouldn't have to transpose everything into EBCIDIC and then triple DES
encrypt it to protect against people that can't read an RFC before writing
their client. If the spec. says that something is opaque, it should be
treated that way.
> 3. Make small editorial changes to style
> d/Bear with me/ etc.
>
> 4. The other schemes make reference to protcocol
> specs, so the URL spec defined the mapping onto
> the protocol but not the protocol. The
> Gopher+ stuff gets quite deep into the protocol --
> is there something to which we could referer?
The Gopher+ protocol is defined by the document
Gopher+.txt
available via anonymous ftp from boombox.micro.umn.edu in the directory
/pub/gopher/gopher_protocol/Gopher+
> Could there be something?
There already is something.
If we didn't spend so much time going over the same points repeatedly
on the URL mailing list we would have had more time to submit the
Gopher+ document as an informational RFC. We intend to do that as soon
as possible since it documents widespread practice on the internet.
In December 1993, 1/3 of the gopher servers on the internet were gopher+
servers, and there are several implientations of both clients and servers.
So we will do an informational RFC about Gopher+... but the protocol has
been documented for a long time.
> If you specify something
> in two places you get into trouble in the end... :-}
>
If you aren't precise about how to map from the URL to the client actions to
resolve the URL, you have a lame URL specification. This became
abundantly clear in the case of the ftp URL even before the Houston IETF.
I wanted to avoid the sorts of ambiguities that characterized the ftp URL,
and to do this it is necessary to explain how the parameters in the URL map
to actions the client takes and do so in gory detail. Without this the URL
is extremely fuzzy and hard to know how to interpret.
> Erik, Alan,
>
> Erik had asked me to produce a draft which did not
> have largely new featueres in it at this stage.
> I'm open to chairman's comments on the above.
>
As of December, 1993 approximately 1/3 of gopherspace was Gopher+ servers,
and the new server growth is overwhelmingly Gopher+. We really need a gopher
URL that can refer to gopher+ items. I went away from the Houston IETF with
the idea that it was largely the responsibility of the Gopher developers to
come up with a good Gopher URL proposal and discuss this on the list, so we
did that. I'm going to be more than dissappointed if this turns out to have
been theoretical/intellectual exercise.
Mark P. McCahill
gopherspace engineer/University of Minnesota
mpm@boombox.micro.umn.edu
612 625 1300 (voice) 612 625 6817 (fax)