Re: report: URN Architecture Meeting at University of Tennessee, Oct 30-31

Just have time for a quick note (meeting all day)...

> I don't know of any way to objectively decide whether the benefits
> of having a "scheme" outweigh the disadvantages.  My experience with
> multiprotocol email leads me to believe that having one "scheme" 
> that is flexible enough to subsume all others, and putting the
> details of how to resolve names in a network-accessible database,
> is far preferable to expecting each client to know the details
> of each "scheme".

And you can do that by defining a scheme which is "better" than all
competing schemes -- clients will implement the best schemes.  The
difference is whether you make the choice of "better" in a committee
standard or out in real-world practice.

> So it's really a case of how much rope to give the clients, and
> how much information to expect them to know in order to do
> their jobs.  I don't mind giving them the rope as long as they
> don't really need to use it all that often.
> 
> I could personally live with having a "name space identifier" (NSI)
> in the URN as long as (a) it's not strictly tied to a protocol or 
> registry, (b) the resolution of the URN doesn't depend on the client 
> knowing details of the NSI portion of the URN, (c) a registry can 
> delegate resolution of URNs on at least a per-(NSI+NA) basis (and 
> ideally, to smaller sub-ranges of that space).
> 
> But somehow I get the impression this isn't what you're getting at.

That is exactly what I was getting at.  All I need is some way to
distinguish between URNs and the assurance that the "best" URN for a
given resource can be decided by the client.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Wednesday, 29 November 1995 21:25:21 UTC