Date: Thu, 14 Apr 1994 17:02:26 +0200
Message-Id: <9404141502.AA21453@dxmint.cern.ch>
From: hallam@alws.cern.ch
Subject: Re: Logical Protocols Was:Re: URL requrements: Structure in string
Dan writeth:
>In message <9404141119.AA22916@dxmint.cern.ch>, hallam@alws.cern.ch writes:
>>Sorry to follow up on my own post but this stuff simplifies the job of URI
>>resolution a lot. At the moment the big problem with URIs is that storing
>>the resolution of every URI is impossible, storing the resolution only of the
>>logical strings is easier however.
>>
>>I propose that given the url
>>
>>$whatever://machine.cern.ch:80/
>>
>Interesting... why not just use Prospero in stead of HTTP for the
>lookup? It has the distinct advantage that it uses UDP rather than
>TCP, and thus requires less overhead and makes less of an impact on
>the net. But I'd have to see a few motivating examples to see if
>propero has all the necessary mechanisms.
Replace instead with `as well' and we agree. We have to work out how to
allow multiple resolution principles though, the protocol field is already
in use... Coule we use multiple protocols?
PROSPERO:$whatever:// ??
or
$whatever:PROSPERO://
I prefer the second since the resolution stuff is incidental to the main
URL idea.
I want HTTP to be *a* resolution protocol because the logical names should
be known to the server. This would enable the server to resolve them
automaticaly in documents sent out under certain content types.
I have had an objection to using environment variables, On UNIX environment
variables are a complete mess, I agree, on VMS they are not ideal. I would see
environment variables as suplementary to rules files. I would also like to
be able to specify a logical in the start of a bit of html, this would be
overidden by a user definition so if we have
<logical LABEL="SPECS" HREF="http://info.cern.ch/specs">
We can then define anchors:
<a href="$SPECS:html">
And so on. This would be very nice for generators since at the moment it is
rather tedious having to store all sorts of data to be able to traverse paths.
One other point there should be some sort of naming system to avoid clashes.
As a starter we could use DNS domain names.
CERN.CH_WWW
Would be an identifier belonging to CERN because we own the names *.cern.ch.
This can be extended to usernames, I would own the name:
HALLAM..axal04.CERN.CH_mine_all_mine
But note that the use of such a name does not mean that I can go to
axal04.cern.ch and ask where the file is. This is because I might have moved,
exploded, joined the NSA or whatever To do that we must have:
$HALLAM..axal04.CERN.CH_mine_all_mine:HTTP://axal04.cern.ch/some_data
Which I would probably declare as a logical name:
$AUTHOR :== $HALLAM..axal04.CERN.CH_mine_all_mine:HTTP://axal04.cern.ch/
Yes we have recursion!!!
OK so this all runs into the URN stuff and does much of the same stuff. But
if this is easier to implement or provides additional functionality and
still satisfies the requirements I don't see that as a problem. A URI starting
with a logical then becomes a URN, if it has a resolution portion then
we can resolve it and we have a URL.
So URI &superset; URL &union; URN
and URL &intersection; URN ¬equal; ∅
Also some people seem to hate the idea of logical names. I can't stand all
the configuration rubbish necessary on UNIX systems because the system
does not know where the files it needs are. I can take software for VMS
and compile on an arbitrary VAX and it usually works, If I take software
for a UNIX platform then either it was written by GNU or I have a lot of
hacking to do because the configuration file never works.
I am working on a operational semantics for URLs based on a protocol compiler I
have written. If anyone has experience with operational semantics I would
appreciate them having a look over the specs as I complete them. Perhaps this
would be suitable for an RFD?
Phill Hallam-Baker