Message-Id: <199402182016.PAA15964@wilma.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: stripes@uunet.uu.net (Josh Osborne)
Subject: Re: caching
In-Reply-To: Your message of "Fri, 18 Feb 1994 14:51:46 EST."
<9402181951.AAwdvb18919@rodan.UU.NET>
Date: Fri, 18 Feb 1994 15:15:53 -0500
> So no URN's can point to 'todays weather', or 'the current USA Today'?
> No URN's can point to live data feeds?
>
> If URN's are restricted to static data only they lose a great deal of
> usefulness. URN's should point to something their owners think is
> appropriate, no more, no less.
I've said many times that I understand that there's a need for URNs that
can point to things that aren't so precisely defined. But in any case,
the binding between a URN and the object it points to (however that object
is defined) is static, even if the object itself can change its bit patterns
within the confines its definition.
> >if the name referred to that object. One way to do this would be for me
> >to ask the publisher to give me an MD5 signature for the object. But this
> >would only work if there were only one valid representation of that object.
> >
> >But without such a mechanism, how can we guard against the error caused by
> >conversions not done by the publisher?
>
> We can only do that if the conversions are lossless, and reversable (and
> you get the origanal format along w/ the MD5). So you can only protect
> a subset of what the URN's can point to.
Yes, but it's a VERY IMPORTANT subset. Probably 99% of the resources currently
available on the Internet fall into this category. And if this system is to be
usable it's essential that we be able to reliably copy around files from place
to place, and be able to know efficiently and reliably whether file X is a valid
instance of a particular URN.
> [...how do we protect vs. lossy conversions by unauthorised 3rd partys...]
> Just don't list URL's that you don't think are "good enough" when
> a request for a URN->URL resolution comes in.
Yes, but this isn't written down anywhere. It may be obvious to you and me,
but it's not obvious to everyone.
> >As I've said many times, I can see the need for a kind of name that refers
> >to any of several representations of an object. But the ability to name
> >the specific representations is *much* more important if you're trying to
> >build a system that manages replication of these objects over a network.
>
> Yes, but should that be solved by URN's, or by a protocall that uses them?
I don't care so much where it's written down, so much as that it's published at
the same time or before the URN spec is published.
I see a URN as a single component of a more complex system. (Without a system
to keep track of URNs and the objects they point to, URNs won't be very useful.)
Designing the component before designing the system is premature.
Say you're designing an automobile for the first time, and you realize you're
going to need a transmission in your automobile. Even before you have done the
detailed design, you have a pretty good idea of the function of the
transmission, and you know it's going to need gears of various types, a way to
let the driver change the gear ratio, linkages to the engine and wheels, etc.
But until you've laid out at least the overall design for the rest of the car,
you don't really know what the specifics are. You could of course design the
transmission anyway and somehow hook it in to the overall system when you were
done, but after doing so you might find out that the resulting automobile had an
unacceptable ground clearance, or that the gear ratios were such that you could
never get the vehicle moving.
Now, we've got a lot of bright people here, and I'm pretty sure that lots of us
have a pretty good intuitive "feel" for what this URN thingy needs to look like.
I'm also mostly confident that the functional spec that Karen and Larry have
laid out is reasonable -- as far as it goes.
But I've yet to see a fully fleshed out outline for how the URN fits in with
the rest of an information retrival architecture, and until we do that, we don't
really know how whether it does fit.
Keith