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

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
Sat, 8 Jul 95 22:31:25 CDT


Date: Sat, 8 Jul 95 22:31:25 CDT
From: liberte@ncsa.uiuc.edu (Daniel LaLiberte)
Message-Id: <9507090331.AA02237@void.ncsa.uiuc.edu>
To: uri@bunyip.com
Cc: Roy Fielding <fielding@beach.w3.org>
Subject: I-D: How Roy would Implement URNs and URCs Today
In-Reply-To: <199507090027.UAA11739@beach.w3.org>

Roy Fielding writes:
 > I apparently missed the deadline by 30 minutes, so here is yet
 > another view of how URNs and URCs can be implemented. 

Hmm, since we (Michael Shapiro and I) were not planning to attend the
IETF meeting, we didn't even think about the deadline.  But I'll be
mailing out a pointer to the latest path scheme draft within a week
anyway.

 >               How Roy would Implement URNs and URCs Today
 >                   <draft-ietf-uri-roy-urn-urc-00.txt>
 > ...
 >    It is my opinion that this search for the "Holy Grail" of URNs is
 >    both misguided and unnecessary.  It is neither possible nor
 >    appropriate for us to define a single URN service. 

Well, it is at least very difficult, and moreover, it is unnecessary.
The only reason for a common syntax is if there is a common semantics,
but the only common semantics we *should* have is the very abstract
URN requirements that should be met somehow, assuming they are even
necessary or sufficient.

 > 4.  URCs are Documents
 > 
 >    The notion of Uniform Resource Characteristics (URCs) has been one
 >    of the central issues in the debate about URN services.  Simply put,
 >    a URC is a set of characteristics regarding a named resource, in a
 >    format that can be easily parsed, which identifies a set of locations
 >    from which the named resource may be obtained.  The URC can then be
 >    used as the intermediate step between resolving a URN address and
 >    determining the most appropriate location (from the perspective of
 >    the client configuration) from which to retrieve the resource.

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.

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?

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

 >    Unfortunately, that's still not good enough.  Current browsing clients
 >    will default to "application/octet-stream" if they do not have a
 >    handler routine installed for the indicated media type (usually
 >    resulting in a prompt to save the document as a local file).  In
 >    practice, this has been a barrier to the wholesale introduction of
 >    new media types.  We need an implementation of URCs that will work
 >    with all existing clients, because without that assurance, content
 >    providers will be unwilling to use URCs as an intermediate step.

I think Java or agents could play a big part in automatically providing 
local services for handling URCs.  (But I still believe agents are beyond
the immediate realm of URIs, although there is a continuum...)

 > 6.1.  The ietf URI scheme
 > ...
 >    The implementation of the scheme handler is a fairly straightforward
 >    address replacement table and associated logic.  For example, the
 >    following could act as the configuration for my local client:
 > 
 >       PREFIX       REPLACEMENT                            AUTHORITATIVE?
 >       ietf:        file:/home/fielding/ietf                     No
 >       ietf:/rfc/   ftp://ftp.ics.uci.edu/pub/ietf/rfc/          No
 >       ietf:/rfc/   http://info.internet.isi.edu/in-notes/rfc/   No
 >       ietf:        http://ds.internic.net                       Yes
 >       ietf:        ftp://ds.internic.net                        Yes

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

Although it does relate to resolution of URIs, it doesn't by itself
help us come up with URN schemes.  It helps us specify how to resolve
any new URI schemes that come along, however.

 > 8.  Acknowledgements
 > 
 >    I have discussed the issues
 >    involved in URI indirection, and URCs as media types, with
 >    Daniel LaLiberte several times, but he is not to blame for this
 >    treatise. 

Speaking of indirection, we have a page on redirects too at:

  http://union.ncsa.uiuc.edu/HyperNews/get/www/redirect.html

It contains some points relevant to the relative URL rfc.

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/