W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

Re: URI Opacity Principle (was: Re: use of fragments as names is irresponsible)

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 15 Jan 2003 20:36:00 -0800
Message-ID: <003e01c2bd19$4fd052c0$f5457743@mnotlaptop>
To: <noah_mendelsohn@us.ibm.com>
Cc: <fielding@apache.org>, <sandro@w3.org>, <www-tag@w3.org>

> Do answers to these follow from your proposal?

hopefully - let's see ;)

> can/should a client keep histories based on  substructure of URIs?

I think this is actually a UI feature, not a URI manipulation; they're
treating them as a pool of opaque (aha!) strings, sorted by alpha and
length, and returning those that match as you type in a string.

> Is it OK for cache proxies to microparse URIs to infer
> clustering characteristics of the information space?

That is, use a URI as input to a freshness heuristic? It's allowed by
HTTP, and sometimes used, but my experience is that it's poor practice,
and repeatedly recommend against it (But I have a general bias against
heuristics in these situations). The caching industry has generally
migrated away from these solutions, especially those surrounding
prefetching (although there is a certain fascination with it in academic

From a URI perspective, I think it's not OK (and falls under my SHOULD

> Is it (or more correctly "why is it") OK for a client
> to actually inspect the scheme to determine a
> retrieval strategy?

Yes, because that's part of the generic dereferencing process, which is
part of my first paragraph (although it should probably be said a bit more
clearly that dereferencing is a special operation).

> Surely it is appropriate for the server to map the HTTP example above to
> file system sub-directories should it choose to do so? (Though of
> that's not required or visible from the outside.)

Yes, because it is the authority that minted the URI that's doing the
Received on Wednesday, 15 January 2003 23:40:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:56 UTC