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

> 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
circles).

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


> 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
course,
> that's not required or visible from the outside.)

Yes, because it is the authority that minted the URI that's doing the
mapping.

Received on Wednesday, 15 January 2003 23:40:17 UTC