Message-Id: <9311241513.AA14611@gac.edu>
To: Rich Wiggins <WIGGINS@msu.edu>
Subject: type info, access info (was Re: Minutes for URI)
In-Reply-To: Your message of "Wed, 24 Nov 1993 00:20:34 EST."
<9311240551.AA06127@mocha.bunyip.com>
Date: Wed, 24 Nov 1993 09:13:50 -0600
From: Erik Ostrom <eostrom@pepperoncini.gac.edu>
> I think Erik is absolutely right on here.
Gee, thanks. Actually, I think I was wrong, but I was unclear enough
that it looked like I was saying what you said.
I don't think we're talking about type information, and I think that's
why I was confused. To me, type information is an answer to "How do I
interpret what I get from this URL?"--it's something like "It's a
postscript document" or "It's a Gopher directory". What we're talking
about is access information, which answers "How do I get information
from this URL?"
Access information like the FTP transfer mode has to be a part of the
URL--you need it for retrieval. But when I read "type information", I
thought of things like MIME types or Gopher0 types (which are really a
mixture of the two categories, which I'll get to). I think we should
be careful to distinguish between these concepts before we start
arguing about whether such-and-such should be part of the URL.
Gopher0 has, as far as I could tell from a quick review of the RFC,
four access types, as far as URLs are concerned:
-- text/directory (read dot-quoted lines)
-- binary (read until connection closed)
-- not-really-gopher (e.g., type 8 `telnet' Gopher links)
-- not-a-URL (what do we do with CSO nameservers?)
Maybe a fifth for type 7 (search), which requires getting a string
from the user.
So I think it's important to include this information, which is
necessary for retrieval. I think including it in the form of a
Gopher0 type is kind of ugly; although it allows us to save a
character by folding access and type into one byte (if we decide type
is a part of the URL),
-- I'd like to be able to provide better type information than the
single character Gopher allows, in passing around Gopher URLs.
-- Clients won't know what to do with some experimental Gopher type
characters, but they could still know how to transfer the data if
this information was provided explicitly.
-- In automatic derivation of Gopher URLs from Gopher directories,
clients will have to infer access from type; but they'd have to
do this at retrieval time even if we fold the two into one.
I don't know if any of the other current schemes require more access
information than is currently contained in the spec; but I think type
information is a separate issue.