From: ccoprmm@oit.gatech.edu (Michael Mealling)
Message-Id: <199404271908.AA02002@oit.gatech.edu>
Subject: Re: Seperating URC format and URN->URC resolution
To: mitra@pandora.sf.ca.us (Mitra)
Date: Wed, 27 Apr 1994 15:08:22 -0400 (EDT)
In-Reply-To: <CoxEBH.GEE@pandora.sf.ca.us> from "Mitra" at Apr 27, 94 04:11:40 pm
Mitra said this:
> 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 would break 2 down into
a) which service
b) How to find that service.
The part about what SHOULD a URC contain seems to me like it should
also go into #1 or maybe even a seperate problem.
> 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.
Agreed but I think your going to always be dealing with both questions
as the same time.
> 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.
I can agree with that. I would clarify it by saying that "implicit in the
definition of the URC there is no specification of which meta-info
is present but that those requirments MAY be imposed by the context in
which they are being used". This is just a slightly different way of
saying that a URC should be able to contain any meta-info but that they
dont' have to contain ALL meta-info.
> 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.
I can't tell if you were serious or not about the windows.ini format
but it was still funny. I agree with the idea but I expect everyone
will still talk about this stuff as one whole problem. I'll try and
seperate out my discussions of each.
As an aside: are you planning on rolling whois++ specific stuff into
your resolution paper or is that out of it's scope? If not then I'm
going to add it to my new(er) URC implementation draft....
-MM
-- ------------------------------------------------------------------------------ Michael Mealling ! Hypermedia WWW, WAIS, and gopher will be Georgia Institute of Technology ! here soon via MIME. Your view of the Michael.Mealling@oit.gatech.edu ! internet is about to change completely!