Re: REGISTRAR

Dave_Raggett <dsr@hplb.hpl.hp.com>

Mail folder: WWW Talk Jul-Oct 1993
Next message: Lou Montulli: "Lynx 2.0.10 Now Available"
Previous message: Erik Ostrom: "Re: mailto: url"

From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-id: <9307121707.AA00362@manuel.hpl.hp.com>
Subject: Re: REGISTRAR
To: raisch@ora.com
Date: Mon, 12 Jul 93 18:07:37 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]
Status: RO

Thanks for all the hard work you have put in on URN's. I too think
it is really important for the future of the net.

I imagine people wanting to include a URN in hypertext links together
with attributes that influence how it is resolved to a URL, e.g. by stating
acceptable formats, or size limits (one might want to select a low resolution
copy of an image or movie).

Can you explain how the protocol can carry such attributes. Also we will need
to generalise the syntax for hrefs in HTML/HTML+ to allow such hints
to be encoded, e.g. using a semicolon as a separator:

        "URN;attr1=val1;attr2;attr3=val3"

The alternative is for the name service to return a list of URLs together
with their properties leaving the client to select the most appropriate one.

URNs seem a good solution to standard bitmaps etc. with local caching of
small/commonly accessed objects. I would like to access the URN name
resolution service in such a way that it works very efficiently for local
copies on my machine. The service calls would ripple up through local
servers, to the wider net.

I assume the name resolution service is based on datagrams (UDP)? 
If so, this places practical limits on how much information can be shipped
in each direction. Sending constraints and letting the name service select
a URL is then better than returning an unbounded list of alternatives.

Perhaps it should run continously, rather than being invoked by inetd.
This would ensure a rapid response for local files.


Dave Raggett