Message-Id: <199404062130.RAA27661@wilma.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: ccoprmm@oit.gatech.edu (Michael Mealling)
Subject: Re: URC's
In-Reply-To: Your message of "Wed, 06 Apr 1994 15:43:16 EDT."
<199404061943.AA08456@oit.gatech.edu>
Date: Wed, 06 Apr 1994 17:30:45 -0400
> >* Some people have suggested that information about locations of an object
> also
> >belongs in the URC. Maybe it does and maybe it doesn't, but locations
> >certainly fall into the nebulous category of "meta-information".
>
> By locations you mean URLs? Most definitly they belong in URCs since
> the location is just meta-info about the name. When you get down to
> it everything ABOUT a resource is meta-information. Only the resource
> itself is not meta-information.
You seem to define a URC to contain all meta-information about an
object. That's fine in concept, but not as a protocol.
> > Observe that different kinds of meta-information get used in different
> > ways. Some are involved in resource discovery, some in resource
> > location, some in access. Some of the elements are used for more than
> > one purpose, so we may not be able to draw clean lines between
> > functional groups of elements.
>
> Correct. That's why it needs to be in one structure.
doesn't follow. Just because it is desirable to use some fields of the
meta-information in multiple ways, doesn't imply that it is desirable (from the
standpoint of protocol design) to put them all in one structure. Even by
creating an abstract "view" of meta-information, you obscure the differences in
how the various pieces are maintained, how reliable they are, and the amount of
time that each piece can be expected to remain accurate.
> You may use an element for resource discovery whereas I use it for
> accounting and audit trails. You draw your line twixt which elements
> deal with which functions and I'll draw mine.
But not all lines are equally useful. If the system as a whole is to be able to
perform certain functions well, some design decisions are needed that determine
which pieces have to have which kinds of accuracy/consistency.
> > It may seem obvious, but I'll state it anyway:
> >
> > The meta-information for a resource needs to be consistent with the
> > resource (and instances of that resource) that the meta-information
> > purports to describe.
> >
> >If a resource changes, at least some of the characteristics of the resource
> >will also change. Attempts to use the "old" characteritics with the new
> >instance of the resource may result in various failures. Imagine what
> >happens when a client attempts to use an obsolete content-type, size, MD5
> >signature, or cost for a particular object ("gee, the URC said it was
> >free...so why is there a charge on my bill?").
>
> That's why I specify that URCs have a Time To Live of 0. You can try
> to cache it for longer than that but it's not gauranteed. With things
> like Cost I would expect the client and server to have someway to
> confirm the cost before the transfer.
If URCs have a TTL of zero, then I need other protocols which provide
better guarantees. By the time I factor out all of the stuff for
which I need accurate information, there may not be too much left that
I can trust to a URC.
Likewise, if URCs have a TTL of zero, then there's no point in trying to
replicate them, because there will be too many applications that need current
information. This, in turn, keeps URC lookup services from scaling.
This is a non-starter.
> >The trick is to design a system by which the instances of resources which
> >are accessed using various meta-information, will be consistent with the
> >meta-information obtained during the process of discovering/locating/
> >accessing the resource.
>
> Good point. I would expect there to be an "authoritative" site for the
> one tried and true URC with just global information being authoritative.
There had better be multiple authoritative sites if you want the service
to scale.
Keith