Date: 06 Apr 94 21:27:47+0200
From: pays@faugeres.inria.fr
To: pays@faugeres.inria.fr, ccoprmm@oit.gatech.edu
Subject: Re: URC's
Message-Id: <765660467.16730.0-faugeres.inria.fr*@MHS>
> >
> > 1. If as karen says any one may have a URC with a different content
> > for the same URN I don't know why this is being discussed in this group,
> > and I would rather call them SRC Specific Resource Context :-)
> > as this is no longer Universal and more a personal and changing over
> > time Context that a specific user associates to an URN.
>
> 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).
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.
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.
> > 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.
>
> > 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 and not thus will not be able to contain informations
about the instances. Again no longer *one bag*.
[....]
>
> > 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).
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
another one (directory type) to make this information available
through the net.
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?
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.
>
> > 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.
regards,
-- PAP
For testing purpose only (and just demontsrate that the above indeed exists)
try (with a form capable WWW browser):
http://perignon.inria.fr:8887/
1.
select document search
select "This server"
then key-in something like
solo,inria,fr
or
www,inria,fr
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