Re: I-D: How Roy would Implement URNs and URCs Today

>A couple points here.  First, I want to point out as a reminder (since
>I've said it a couple times already) that it is not necessary to
>resolve URNs into URCs or URLs in order to support the location
>independence that we all desire.  An explicit indirection is one way
>to go that works fine with URCs or URLs, but the indirection can
>instead be implicit, and it is resolved by way of resolving the URN.
>The path scheme uses implicit indirection.

Yes, I mentioned that later.  If what you get back determines whether
or not there is explicit indirection, then we don't have to require
explicit indirection in "the standard".

>Second, although it is valuable to consider a URC as a document (or an
>object, or a resource that is interacted with), it is important to
>acknowledge that the URC is different from the document that it is
>"about".  It is different not necessarily in type but in the sense of
>data vs metadata.  Metadata is data too, but *as metadata*, it is not
>the data we are referring to.  If we don't make this distinction, how
>can we refer to the URC itself as data?

By providing a toggle on the client that says "show me the metadata",
or a shift-alt-click thingy that prevents auto-indirection.  This is
only an issue for browsers.

>So we need to either know in advance (based on the protocol or how it
>is used) that what is coming back from a resolution is the data itself
>or that it is the metadata, or we need to be able to identify which it
>is similar to how MIME types are used to identify the type of the
>document.

The latter is the only (IMHO) practical way to do it, which is why
a urc/* major type is needed.

> Since it is a binary flag, it seems a bit much to have an
>additional header line or whatever just to indicate that the content
>is data vs metadata.  It seems simpler to have the URN (or URL for
>that matter) refer to the data by default, and have some other
>explicit method for accessing metadata instead.  Another reason
>for doing this is that it isn't "the metadata" since there are many
>possible metadata sets that might be available.

You will only get one response to a retrieval request, even if that
one response is a merging of several URCs into one.  In that sense,
it is "the metadata".  However, the whole point here is that you shouldn't
need to know ahead of time whether the pointer is to a URC or to the
actual resource (in fact, I believe it is impossible to know that ahead
of time, because the person issuing the request may have a local cache
of resources-by-name, regardless of the possible existance of metadata).

> > 6.1.  The ietf URI scheme
> > ...
[config table deleted]
>
>This looks like what we are developing as a generic proxy mechanism.
>Read what we are thinking at:
>
>  http://union.ncsa.uiuc.edu/HyperNews/get/www/proxies.html

Hmmm, interesting, but I would make it more general -- make it a choice
between proxy or replacement (i.e., internal redirection) and you've
got a winner.  Also, you should be able to download initial configurations
from a replicated central site, indexed by network location.  Ack, but
now we are talking WWW design issues, and I shouldn't do that here.

......Roy

Received on Sunday, 9 July 1995 17:51:22 UTC