Message-Id: <9310152227.AA14563@expresso.bunyip.com>
From: Peter Deutsch <peterd@bunyip.com>
Date: Fri, 15 Oct 1993 18:27:06 -0400
In-Reply-To: Marc Andreessen's message as of Oct 15, 7:36
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: The URN: wrapper and URLs...
Hi again,
[ Marc wrote: ]
> Peter Deutsch writes:
. . .
> > God forbid that we should preserve that ridiculous and
> > unnecessary double-/ syntax in the URNs as well! I don't
> > object to making it optional to avoid breaking previous
> > code, but it's such a blatant hack that it really offends
> > my sense of artistic balance no end... :-(
> >
> > Having vented my spleen on such a minor topic, my vote on
> > the topic of consistent wrapping would be to make the
> > <UR*:[opaque string] > format the standard for the whole
> > family.
>
> Conspicuously missing from your counter-proposal is a mechanism by
> which a client knows where to go to locate (or dereference) the
> resource. Could you elaborate?
I'm not sure I'd qualify what I posted as a
counter-proposal. Rather it was a "rumble of agreement",
weighing in in favour of those arguing for orthogonal
design and clearly identified URL and URN labels, on the
assumption that we don't know exactly what these are or
what we will do with them so we should be a little careful
not to colour outside the lines or make too many early
assumptions that we might regret later.
I don't see that this particular suggestion should be all
that much of a bear to support, a number of people in the
group seem to like the idea and I thought I'd mumble "me
too".
I'd like to reiterate the view that we don't really know
all the uses these things will be put to, so we shouldn't
plan on limiting ourselves to the "fetch file" paradigm at
this point. If we push our brains a bit to think in terms
of interactive services, live data feeds and so on, perhaps
the distinction between a URN and URL can become more
real. Of course, maybe others are right and there isn't
one. I personally suspect there is, but the debate is
certainly in order at this point to help explore the
issue.
- peterd
--