Message-Id: <m0pvqtG-0004JAC@inca.gate.net>
Date: Tue, 26 Apr 94 13:25 EDT
To: ccoprmm@oit.gatech.edu (Michael Mealling)
From: hoymand@gate.net (Dirk Herr-Hoyman)
Subject: Re: Yet more URI/URC
At 12:53 PM 4/26/94 -0400, Michael Mealling wrote:
>I'm planning on my next version of the URC paper proposing a set of
>elements that we need right now:
>
>Size
>Content Type
>Cost
>Title
>Author
>Version
>
>Can you think of anymore?
>
Date, for sure. Language too, IMHO. This is about the size of the list I
had in mind.
>> Full would be anything/everything. I'm concerned that this will entice
>> some to put into something like a MARC record, that would be bad (not short
>> and sweet). Rather than putting lots and lots of attributes into a URC, I
>> feel it would be better to point to another source of meta-data, such as a
>> library catalog (or full whois++ or X.500 or ...). While not wanting to
>> constrain possible innovation, this innovation ought to be oriented towards
>> IIR use, not a general directory service.
>
>This is where I start disagreeing. I know of large numbers of people who
>will want to ENCODE THE INFORMATION AVAILABLE in a MARC record in a URC.
>I don't necessarily want an entire MARC record in there in it's raw
>form but the same information could very well be in there.
>
>> If we buy into this model, it would imply 3 templates for URN/URC lookup.
>> Having both a minimal and full template would allow for innovation, without
>> throwing a large URC at clients that don't want them. Presumably more
>> "standard" templates could be defined, but not more than a handfull. We
>> might, then, make recommendations as to what attributes ought to be in a
>> minimal template, though URC servers could provide whatever fields they see
>> fit. I don't believe that negotiating a template to use is a good idea
>> (too much overhead), though that might be possible.
>
>You don't need to negotiate which one you want. That's something that
>is best left up to the resolution method we end up with. That's
>why I like whois++. My client can say something like this:
>
>template=urn;URN=bla:include=URL
>Which gives you your location example
>
>template=urn;URN=bla:include=URL,size,content-type,cost,title,author,version
>which gives you your minimal example
>
Ok,there's the rub, Michael. You have to know which attributes to ask for.
That's going to change. What I is suggesting is that we create a
convention whereby there is a template called minimal (for the sake of
argument) and the URC service puts in it the elements it wants. Maybe it's
not hard to do what you are showing us and maybe it can be hidden. But,
what I don't want to see is a situation where clients have to ask for the
entire URC, if we have folks creating large URCs.
>> And this needs to be
>> fast, which is not mentioned in Michael's document either.
>
>That document is a list of requirement for a URC. The above requirment
>is for the resolution protocol which should be addressed in another
>document. I agree it needs to be as fast or faster than as DNS but
>that is not something that can or should be made a requirement of
>something that doesn't have the conept of being fast or slow.
>
Well ... ok, but a URC that takes a long time to fetch is of little use to
me. This is a requirement, and I don't really give a hoot which spec it's
in. Methinks we've got a bit of reductionism going on here. We need to
think more wholistically. It's an architecture we are creating, not just a
bunch of pieces that we are going to hook together at a later date.
I'm perfectly happy to let there be large URCs that can contain any
imaginable meta-info, but this CANNOT interfer with the basic fundamental
purpose, which requires the operation to happen quickly. There are other
directory services for that, IMHO.
-- Dirk Herr-Hoyman | CyberBeach Publishing | Practice * Internet publishing services | random acts of kindness Lake Worth, Florida, USA | and hoymand@gate.net | senseless beauty +1.407.540.8309 |