From: mitra@pandora.sf.ca.us (Mitra)
Subject: Seperating URC format and URN->URC resolution
Date: Wed, 27 Apr 1994 16:11:40 GMT
Message-Id: <CoxEBH.GEE@pandora.sf.ca.us>
We seem to be deanling with two seperate questions here, I'd like to see
if we have agreement on this, so that we could push forward on them
seperately.
Question 1: What does a URC look like, what CAN it contain, and how is
it formatted.
Question 2: In the case of a URN->URC resolution service, what SHOULD a
URC contain, how will it get used, how will we find the resolution
service etc.
I think that these questions are seperate enough that we could
potentially come to an agreement on question 1 before deciding question
2, allowing people to start using them in experimental URN->URC
resolution services, and otehr situations where a URC is needed. Its
possible that experience with experiments, and discussion of question 2
will end up modifying our format. But my guess is that any of the
proposed solutions to URC format would meet the needs of any of the
requirements I'm hearing for URN->URC resolution.
The consensus I hear on Question 1 is that a URC is a collection of:
zero or one URN's, zero or more URL's, and meta data associated with any
of these. That implicit in the definition of the URC there is no
speecification of which meta-data is present, but that those
requirements would be imposed from the situation in which they are used
- e.g. we might say that a URN->URC resolution service returns certain
fields, but these wont neccessarily be the same fields returned by a
resource discovery service.
If there is general agreement that these are seperate issues then we can
go on to consider the different proposals for URC format (RFC822 style,
lisp style, SGML style and Windows .ini format), in parrallel to the
discussion of resoltuion services.
- Mitra