Re: Excess URI schemes considered harmful

----- Original Message -----
From: "Roy T. Fielding" <fielding@ebuilt.com>
To: "Harald Alvestrand" <harald@alvestrand.no>
Cc: "Al Gilman" <asgilman@iamdigex.net>; "Eastlake III Donald-LDE008"
<Donald.Eastlake@motorola.com>; "'Rob Lanphier'" <robla@real.com>;
<uri@w3.org>; "Dan Connolly" <connolly@w3.org>; "Tim Berners-Lee"
<timbl@w3.org>; "Larry Masinter" <LMM@acm.org>; "Dan Zigmond"
<djz@corp.webtv.net>; "Rich Petke" <rpetke@wcom.net>
Sent: Wednesday, September 26, 2001 2:05 AM
Subject: Re: Excess URI schemes considered harmful


> > roy: the worst thing with relative URIs is that at any time, there is
only
> > one base. If you have stuff from 2 naming trees at the same time, you're
in
> > trouble.

That is what namespaces are for, of course - when you have a langauge
with namespaces.

> On the contrary, I can have a hundred different bases for which a given
> relative URI can be resolved, just as we can have a hundred different
> repositories for standard MIME types.  Since I only use the relative
> parts within the protocol syntax (unless it is a non-standard extension),
> it really doesn't matter to me what the base is, provided that I pick one
> (or allow the user to configure one) that points to at least one existing
> namespace that is managed by the IETF.  "text/plain" is a relative URI.
> For this type of identifier, I simply don't allow relative names outside
> of those within the standard namespace, and I pick the base according to
> an algorithm that is different from web page retrieval.

Having an http:  URI doens't mean you *have* to retrieve a page every time
the URI
is encountered.  There are all kinds of ways you can know what it stands for
from having it programmed in to having a persistent cache (catalog).
But it *does* provide a way of IANA providing  *definitive* information
about that URI.
Such as binary grammars, and conversions between types, etc, [pointers to]
definitive
specs. Because when you use DNS to look up the URI owner's server and ask
that server for a representation of the resource, what you get, inhaving
been
authorized by the owner of the URI, is to that extent authoritative. And
that is useful.

> Personally, though, I don't see any reason to standardize all IANA field
> values as some sort of URI or another.  A media type is simply an
identifier
> within a given context, and the Content-Type field name is more than
> sufficient to establish that context.

For every field which has a extensible set of string values, it is
traditional to invoke
IANA  to deal with the problem.  This doesn't scale.  I see a purpose for
IANA
both historically and in the future as an accessible persistent store, and a
link with
the standards process which provides a set of specs which have a claim to
quality and interoperability.  But it should only be thought of as covering
those
resources which need to be common and shared globally. There should also
be room in the architecture for ones which are local or experimental, etc.
This is achieved by malking the IANA space a subset of URI space, a subset
whose
special place is special because of the way IANA is run.

> ....Roy
>

Received on Tuesday, 30 October 2001 08:12:09 UTC