Message-Id: <9311240026.AA02594@expresso.bunyip.com>
From: Peter Deutsch <peterd@bunyip.com>
Date: Tue, 23 Nov 1993 19:26:06 -0500
In-Reply-To: Dirk Herr-Hoyman's message as of Nov 23, 8:55
To: hoymand@joe.uwex.edu (Dirk Herr-Hoyman),
Karen R. Sollins <sollins@lcs.mit.edu>, uri@bunyip.com
Subject: Re: URL query
[ Dirk wrote: ]
[* Karen's call for a generic URL format deleted *]
> My initial reaction is "can't we just use URNs for this?" If URNs can be
> used to negotiate location, they could also negotiate access methods. The
> whois++ template certainly can accomodate this info.
Side comment before the big show, I don't think we want to
deploy URLs which _requires_ a working URN mapping service
before it could be usable. That's a formula for tomatoes
from the peanut gallery for sure. I don't think that is
what either Karen or I are suggesting, and I'd be leery of
proposals for such approaches myself.
>
> This becomes just another dimension of the mapping URN -> URL. We've
> talked about the URL and format already, this would amount to breaking down
> the URL into a FQDN and access method, which is there for the taking in the
> URL.
Suppose Karen's proposal had been simply for a form of
"compound URLs" (which is _not_ what she's asking for, if
I'm understanding her correctly). In such a case I think
most people would agree that such a concept could be
useful (eg. "Here's a filename, a host, and it should be
available through either ftp or gopher, your choice"). If
all the access method info is included the client could
then choose the "best" (by its measure) protocol to use
and we're off to the races. All we'd need to do would be
to agree upon compounding rules and we're done.
I suspect that the hesitation we're encountering is
because both Karen and I seem to be implying that we can
have real live URLs without actually specifying all the
actual access protocol info to be used. I do suspect that
this is actually practical and at times will even be the
preferred thing to do but if I'm reading the reaction
correctly, we owe the list an explanation of our thinking.
Consider instructions of the form "open a TCP session to
this port, hand the server this opaque string and you'll
get back all Internet users named Deutsch". This is
obviously all the information needed to allow you to pick
up plenty of user records, without even knowing the real
directory search protocol being used.
Now, taking it one step further, what if you connected to
a machine, said "run this program, save the results into a
file named foobar, launch this second program on that file,
then let me see the results". This would, at first glance,
be far different from what we've been calling a URL, but
that's only at first glance. In reality you'd have no way
of distinguishing the results of such a request from a
conventional dereferencing of a "ftp://host/whatever" type
URL. Of course, we'd need to consider this approach in the
light of the newly minted functional specs, but I suspect
it might pay dividends in the future, as we start dealing
more wil byte streams, "virtual info objects" and other
oddities, and less with random collections of files and
the occasional telnet session.
> Certainly URLs could be extended, but there is still a negotiation that
> must occur. If we add to the functionality of URLs (URL++), are we
> subverting URNs? . . .
I don't see us subverting URNs, since if we examine the
functional specs for both URNs and URLs, you'll see that
we're not eliminating the need for URNs at all. These
"descriptive URLs" can't be compared for equality (a
feature of URNs), wouldn't be any more long lasting than
conventional URLs, and so on. All we're doing is
generalizing the URL concept and separating the access
protocol info from the generic idea of providing the
location information needed to allow a clever user agent
to access the object.
> . . . I'm inclined, at this point, to just concentrate on the
> URN lookup mechanism, and then see if it could be used for the purpose
> Karen has in mind. I also think it would be better to have a simple URL
> layer and add functionality on top, ala URN.
I can't speak for Karen, but I do see the value of
planning for additional functionality in URLs. As one
example, I've been saying for a while my concept of a
WHOIS++ URL will include the ability to specify a "search
URL" which in fact may return anything from zero to many
hits. Several people in Houston seemed hostile to the idea
at first (I was told that URLs should refer to objects),
although I think I won everyone around in the end.
The point I was making there (and repeating here) is that a
search URL is in fact somewhat descriptive (it doesn't
just list the info to fetch a single object, but in fact
contains the info needed to construct a "virtual object"
on the fly. The results coming back would appear to be
perfectly valid under the terms of our agreed upon
functional specifications for URLs and in fact
indistinguishable from a conventional file to the caller.
>From what Karen is saying she'd like to work on
generalizing this idea even further, and I agree that there
appears to be value in doing this. I'm not sure where this
will lead (hence we all agree that it wont make it into
the long-delayed current doc), but I think it will help in
the push to move the current URL spec away from its
"filesystem" bias.
If there is general consensus that this is out of scope,
I'd be happy to go off to a more private list to discuss
the idea for a while, but given the problems in reaching
initial consensus on the first URL, I would have thought
there some value in working this out in public.
- peterd
-- -----------------------------------------------------------------------------"The Internet destroys the Greek tragedy of time and space..."
- Daniel Pimienta <pimienta!daniel@redid.org.do> -----------------------------------------------------------------------------