From: atotic@ncsa.uiuc.edu (Alexsander Totic)
Message-Id: <9404060312.AA14442@void.ncsa.uiuc.edu>
Subject: Re: Seattle minutes
To: uri@bunyip.com
Date: Tue, 5 Apr 1994 22:12:28 -0500 (CDT)
In-Reply-To: <199404051604.AA27434@oit.gatech.edu> from "Michael Mealling" at Apr 5, 94 12:04:12 pm
> > The important word here is "I". YOU may think you know exactly what
> > they will do, but the output of this group (if it is to have any)
> > must be an AGREEMENT on what they will do. We don't currently have
> > such agreement, and as far as I can tell, we don't even have a shared
> > UNDERSTANDING of where we disagree (though we are getting closer).
>
> Good point. Should I write everything down that I think URIs should be?
> It actually makes good sense when you look at it all together...
> I wrote the requirments such that you could encode everything that
> everyone wants to encode (libraries:MARC records;CS folx:document
> structure and format;users: cost and size;accountants:audit trails;
> law enforcement:accountability, etc). Now that I think about it it
> actually make sense that we worked out URLs and URNs the way we did
> before we came up with a set of functional requirements.
Why don't we start with the lowest common denominator:
- URC will contain the metainformation about the URN.
>From this definition, it is obvious that one can never specify all the
information that can be stored inside the URC. Some fields will be commonly
used, and we should specify these, so that smart clients can parse them.
We also need to define how will different fields within the URC be
specified, so that clients can parse it. The most commonly mentioned format is
RFC822 header style, which has the advantage of being widely used, and human
readable. If needed, we could extend this definition to allow associations
between attributes. (URL[0]: url:mine. Format[0]: application/rtf).
With this simple spec in place, we can make up some access scenarios and
move onto hard problems.
I will try to come up with a few examples of problems that I have thought of:
Many clients would need only a part of the URC. For example, the WWW client
would in most cases only request a list of URLs. Search client would look at
abstract information. Curious client would ask for the whole URC and
display it to the user.
When server responds to the URC request, it needs to know what fields
to send back. This would be best defined in the protocol used for the
resolution.
I can also think of scenarios where I would like to have a URN + a selector
that refers to the particular field inside the URN. Example is a URC that
contains information about 10 revisions of a document, and I want to point
to a particular one.
The hard issues arise when designing a protocol for URN->URC resolution.
What should be in this protocol? Should the protocol be really simple,
with a single GET command, or should we add facilities for searching,
database updating, etc. Would a single protocol for different URN->URC
scenarios be desired at all?
> > There's a chicken-and-egg problem here. We need to agree on vocabulary
> > before we can discuss the proper function of each piece of the system, but
> > it's impossible to define what a URC is without specifying its function.
>
> Definitly! I just decided to try and build a little bit of chicken so
> I could start talking about the egg (did that make sense? ;-)
We do have the gibblets (resolution scenarios). Lets try defining a
part of the system around them, and then accomodate the system for other
uses.
Aleks
--
Aleksandar Totic -- MacMosaic developer -- atotic@ncsa.uiuc.edu
Software Development Group National Center for Supercomputing Applications
http://www.ncsa.uiuc.edu/SDG/People/atotic/alex.html