From: ccoprmm@oit.gatech.edu (Michael Mealling)
Message-Id: <199404062045.AA10879@oit.gatech.edu>
Subject: Re: URC's
To: pays@faugeres.inria.fr
Date: Wed, 6 Apr 94 16:45:35 EDT
In-Reply-To: <765660467.16730.0-faugeres.inria.fr*@MHS>; from "pays@faugeres.inria.fr" at Apr 6, 94 9:27 pm
pays@faugeres.inria.fr said this:
> > But it's Universally understood. A URC contains things that should be
> > Universal but may not be resolvable....
>
> The following has to be clearly decided and stated
> either a URC is just a concept there will never be any computer entity
> associated with it. Then from now on, no one will be allowed to state
> on this list I will GET the URC from URN using a protocol.
> I would thus maintain my claim that this is only a SRC(ontext).
No.
> or a URC has indeed a computer representation reachable over the
> network and it can be retrieved using a name server type
> directory request when providing the URN.
Yes.
> In that case the URC has to be located somewhere, it is no longer a
> concept of a bag containing all the meta information bound
> as well to the document as well to the different instances
> and versions (because these will be located in potentially
> hundreds or thousands of locations many of them unknown.
No. Only those parts that are pertinant to what the user wants will
be in the URC. If the user wants ALL meta-information then he damn
well better be ready to wait for the query to go out and harvest all
of the associated servers that might contain sometype of meta-information
about that given URN.
> > > 2. To say that an URC is a bag of attribute-value pairs and an help
> > > to locate/access a document and that the URC will contain the
> > > indication/locator/address of a mapping service does not make sense
> > > (from a very pragmatic point of view):
> > > That would imply that the associated URC is obtained magically
> > > from a URN....
> >
> >
> > There will be a protocl for URN->URC resolution so it's not just
> > obtained magically. We're trying to divorce several discussions from each
> > other since they dont' really apply since we just say "the protocol will
> > handle that" without muddying the current discussion.
>
> Avoiding to muddy the discussion has in my mind exactly the opposite effect
> it muddies the concepts and the terminology.
> The is an urgent need to clarify that point.
You've confused me with this one. Clarify what point?
> > > What can be done once we have a name (URN) and only the name?
> >
> > Just hand it off to your favourite/closest URN->URC resolver and get
> > back a URC that's as big and complex as your (or your client) can handle.
>
> OK but the fact that the information in the URC will comme from
> a single server
Nooooo..... I never said from one single server. When you ask an archie
server for something what actually happens (you can correct me Alan) is
that those servers have agreed to harvest certain sections amongst each
other then they each trade sections of the database that the other wants.
Here's a scenario:
I have URN:this_is_my_URN.
I ask my uri.int server for x amount of meta-info about that URN.
That server then says" hmm...here's what I have. Let me check some of
my peers and larger domain server if they have anything."
It then asks the other servers on the net if they have anything
that might be pertinant (yes you have things like tree pruning,
caching, effeciency algorithms, etc.).
Once it gets ALL that back it then puts it all in one URC and hands
it off to the user.
> and not thus will not be able to contain informations
> about the instances. Again no longer *one bag*.
It's one bag but you can put as many things in it as you want. It's one
bag (URC) but I can make it as big a bag as I want and I can tell the
server to put as many thingies in it as I request.
> > > By location service I understand something a la Archie which will
> > > know of the existence of specific copies/instances. However
> > > in this second case plenty remain to be defined for the
> > > spec to become "implementable".
> >
> > Take a look at the whois++ specifications. I like it and there is some
> > beta software out there somewhere.
>
>
> I know and the SOLO stuff we have (see below) is using the concept
> of centroid from whois++. What I wanted to say is that
> before using any kind of directory there is a need to collect
> the information that will be made available through the directory
> (whatever the name and protocol).
You can't. It is impossible. We tried it. Just ask anyone that was
a member of the Non-existant Data Element Working Group. In order
to do that you would have to get the library community, networking
community and the publishing community to agree on what the hell
simple things like Author mean. It will never happen. Make it
extendable and somewhat structured and everyone can use it without
agreeing on it. Maybe several hundred years from now you can get
agreement but it won't be anytime soon.
> What is apparently not studied so far is how to collect this information
> automatically without requiring any one putting available
> a copy (instance) of a resource somewhere being obliged to
> explicitely have to update a directory.
> In my mind there should be
> a tool/service to automatically collect the information of the
> existing instances
It ususally goes the other way around. Archie just did an ftp to
a machine and did a recursive ls. Once it caught on and people felt
like it was worth the investment THEN they wrote efficient harvesters and
update methods.
> another one (directory type) to make this information available
> through the net.
Which came first in the archie sense. There is going to be a ramp up
period where we do all this by hand. Then we hirer undergrad students to
write update programs.
> The big remaining problem is what entity and how the selection process
> will be performed enabling someone to effectively access the instance
> closest and cheapest to her/him. Client? Server? Dynamic evaluation?
> predefined? based on which criteria?
I think some of that is coming out of the lower layers. Anycast and
multicast will probably help.
> That is the only and single issue I really see, the rest being
> only a metter of choice of technology most suited to perform
> the required duty.
Finding the 'closest' machine is best left to those that know what
'close' is. I'll leave that to the IPng folx. ;-)
>>> Hope these remarks will help to focus this URC debate to realism/pragmatism?
> >
> > Hhehe....some have accused me of being to pragmatic! I want this system
> > to be VERY easy to build. Currently I have to spend to much of my time
> > with secretaries who want to publish on the net. I want something that
> > is easy for them to do.
> >
> > Like Karen said, alot of us agree on alot more than we realize. I
> > think you and I agree for the most part except that I have a fairly
> > concrete resolution scenario in my head.
>
> Not completely true.
> Not only I have a concrete scenario in mind, but we also have
> an experimental prototype working here:
> . the URN for us are DN (understand X.500 Directory Names)
> . the resolution protocol is SOLO
> . the URC is the entry which name is the URN (the set of attr in that entry)
> and it contain locators for different versions and formats
> Of course we certainly not pretend it is the ultimate solution
> . it is probably not fast enough for plenty of usage
> . it is unclear how a directory will know how to select
> the locator *closest* to you
> but it works, is scalable (eg. CLDAP might provide the UDP
> speed for real name server responsiveness), allow to combine
> (limited) searches from an interactive user agent, with name server
> type of usage for simple and fast URN -> URL resolution,
> we have even developped a libwww module which knows how to
> handle these URNs (ie. make the directory request URN -> URL)
> enabling thus to have URN in our documents instead of URL only
> when using the enhanced version of Mosaic linked with that
> additional commolib module.
> This is only a prototype to help understand the issues, to test
> the proposals, but this clearly helps us to remain extremely pragmatic.
> In fact we had been silent so far just because we were not able
> to understand the URI group proposals and wanted to have
> a better and extremely concrete understanding of requirements
> and possible solutions before getting involved into the game.
Ah....your coming from an X.500 universe.....
>
> You will be returned first a selection of suggested URN
> Then cliking on anyone you will be returned the associated URC
> then a click on one of the possibilities (in fact URL)
> will give you access to the document
>
>
> 2.
> select "Absolute Match" AND URL as the only requested Attribute
> then key-in an exact URN
> (eg. solo-internet-draft,inria,fr)
>
> and you will get automatically the document itself (in fact the one
> associated to the "default" URL present in the URC)
> -- in that case through a ftp to the norvegian Internet Draft repository
That's my entire scenario. I just use whois++ and dont' use X.500
terminology.
-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!