# URC's

Karen R. Sollins (sollins@lcs.mit.edu)
Tue, 5 Apr 94 19:41:49 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Karen R. Sollins: "Authentication Problems"
- Previous message: Keith Moore: "Re: URC's"
- Next in thread: pays@faugeres.inria.fr: "Re: URC's"
- Maybe reply: pays@faugeres.inria.fr: "Re: URC's"
- Maybe reply: John A. Kunze: "Re: URC's"
- Reply: Michael Mealling: "Re: URC's"
- Maybe reply: pays@faugeres.inria.fr: "Re: URC's"
- Reply: Keith Moore: "Re: URC's"

    Date: Tue, 5 Apr 94 19:41:49 -0400

    Message-Id: <9404052341.AA26944@zippy.lcs.mit.edu>

    From: Karen R. Sollins <sollins@lcs.mit.edu>

    To: uri@bunyip.com

    Subject: URC's

I don't know whether this will clear the air or only make it murkier,
but let me try this.

First, about the "name". Originally, Michaal, I believe, proposed
that the "C" was for "citation". I believe (correct me if I'm wrong)
that that derived from the observation that this was supposed to be
meta information about an object of the sort found in library
citations. It made a lot of sense. I suggested later that we extend
that concept by using "C" for "characteristic" because I was trying to
generalize the concept. In my work, and therefore I can only assume
in others as well, there will be use for meta-information that does
not look like citation information, although some of it will. Hence
the generalization. This part is really not a big deal.

Now, about "what they are," a much more important issue that "what we
call them." We have need of a collection of information about an
object, that is not the object itself and may be mutable or sometimes
unreliable. For example, since the URN->URL mapping service is not
identified in the URN (a good thing in my opinion, since it may change
with time), having hints around of likely mapping services to try
would be useful. Of course, this isn't useful information if only
stored with the object itself, but definitely useful meta-information
about the object. In fact, location hints may be URL's, addresses for
mapping services, names (that in turn need to be mapped into
addresses) for mapping services, or other useful information that may
lead to useful mapping services. (An example of this might be that
the object I want to find is a movie produced in Hollywood, so asking
a third-party mapping service that has made it its business to know
about the locations of American films might help me find its
location.) Another sort of meta-information that might be useful is
access control policy information or cost policy so that I might be
able to figure out without incurring network transmission costs
whether or not I would be allowed to access the object in question or
would want to based on pricing. These also may change with time, so
if I really want to access it, I might not want to trust my copy of
the URC information. Of course, that original citation-like
information may also be useful

There are several interesting points about URC's as I have suggested them:

1) Their purpose is to aid in accessing an object. It may be that
they contain all the information I need about an object at present, or
they may help me in finding more about it. [If we consider levels of
abstraction, URNs, the resources themselves and URCs fall into the
level of abstraction that we are designing and building. URL's are
part of the interface to the supporting transport layer.]

2) There is no one answer about their content. I have always viewed
them as bags of attribute-value pairs (with the option of an attribute
appearing more than once).

3) There may be multiple versions of them. For example, if I find
that a particular mapping service is useless, then I may choose to
delete it from my local copy of the URC, so I won't try it again. I
might have found a really useful mapping service that I use instead,
so if my friend asks me about the URC for an object, I will report one
thing. You may have found that the original mapping service was very
useful, so you continue to use it, and if my friend asks you about the
URC, you will report what you believe is useful. Another example of
where they might vary is in that different instance of an object may
have different pricing policies or access control policies (determined
by the storage service on which they sit, for example). I may choose
to only retain information about particular instances I think I will
want to access later. At these point our views of the URC will have
again drifted apart slightly.

4) When URN's are passed around, there is some URC information that it
would be very useful to pass along with them. I imagine that that may
change both with different sorts of objects and with time. It is
probably a good idea for us to declare a recommended set for a
starting point, although I don't think we can/should mandate that
there is exactly one set and we know what it is. My guess is that
there will be a great deal of overlap between this list and that
original list of citation information. It was a very good starting
point, and maybe ending point at least for the present.

I'm sure there are some other words of wisdom (:-) that I might say
here, but I can't think of them now. The bottom line is that I think
there are a number of people on this list who have a good idea of what
URC's are about and I also don't think that those views are very far
apart. In Seattle we jumped into perhaps the middle of an ongoing
discussion, rather than backtracking. This is something that we have
to do if we are to make progress, although it seems that perhaps this
time, too much context had been lost and confusion and
misunderstanding ensued.

I hope this helps focus the discussion on the subject matter.
Karen

- Next message: Karen R. Sollins: "Authentication Problems"
- Previous message: Keith Moore: "Re: URC's"
- Next in thread: pays@faugeres.inria.fr: "Re: URC's"
- Maybe reply: pays@faugeres.inria.fr: "Re: URC's"
- Maybe reply: John A. Kunze: "Re: URC's"
- Reply: Michael Mealling: "Re: URC's"
- Maybe reply: pays@faugeres.inria.fr: "Re: URC's"
- Reply: Keith Moore: "Re: URC's"