Re: [Fwd: Re: Approval of initial Dublin Core Interoperabiity Qualifiers]

Hi Martin,

Not following the entire discussion, here is my opinion on some of these
issues...

First of all, there is only one handle syntax (see
http://www.ietf.org/internet-drafts/draft-sun-handle-system-def-02.txt),
defined as :

     <handle> ::= <handle naming authority> / <handle local name>

On top of the handle syntax, there are these different URI syntax
definitions under discussion:

A) Handle URI Syntax, defined as:

hdl:<handle>
   ;subject to URI syntax definition, using handle system protocol


B) Handle URN Syntax, defined as:

urn:hdl:<handle>
   ;subject to URN syntax definition, using URN protocol


C) And, there is also what we called the Handle Proxy Syntax, defined as :

http://dx.doi.org/<handle>
   ;subject to HTTP syntax definition, using HTTP protocol


These suggest that,

1)  Handles can be resolved directly from handle aware applications, or via
its URI equivalence from web-browsers that support the URI schema. Handle
System defines a name service that is not limited to any URI namespace. It's
like sending email. One can send out email using <email-address> directly.
Or he can use the email URI syntax, like mailto:<email-address>, from a
web-browser.

2) Each handle URI syntax definition utilizes a different interface to the
handle system. Personally, I would suggest using "hdl:" syntax which is most
efficient and offers the security not offered by any of the others. However,
this would need client to install the handle system resolver, which is hard
to enforce and is also why the Handle Proxy Syntax is (probably 'forever')
used.

The reason that I think using "hdl:" syntax (or handle protocol) is more
efficient compared to using proxy (or http protocol) is because:

a) handle protocol is a binary encoded protocol. It is more efficient
compared to http protocol that is encoded in ASCII text.
b) handle protocol can use UDP as the underlying transport layer protocol,
while http relies on TCP for each URL resolution.
c) handle protocol allows shared network resources (e.g. tcp channel) among
multiple requests.
d) handle protocol does not use or rely on DNS. There's no inherited
overhead as http does.
e) handle protocol allows secured name resolution without having to
establish any SSL session beforehand. It also defines an access control and
administration model that allows handle and handle values to be managed
directly.


By the way, the existence of multiple handle proxy servers is due to
historical reason that individual organizations set up their own proxy
servers to talk to the handle system.


Regards,  Sam


----- Original Message -----
From: Martin J. Duerst <duerst@w3.org>
To: Larry Lannom <llannom@cnri.reston.va.us>
Cc: Ray Denenberg <rden@loc.gov>; W3C URI List <uri@w3.org>; Norman Paskin
<n.paskin@doi.org>; Sun, Sam X. <ssun@cnri.reston.va.us>
Sent: Thursday, May 11, 2000 3:59 AM
Subject: Re: [Fwd: Re: Approval of initial Dublin Core Interoperabiity
Qualifiers]


 > Hello Larry,
 >
 > At 00/05/10 21:44 -0400, Larry Lannom wrote:
 > > >Using http://handle.org/ or some such
 > >
 > >Right. In fact, that has been the case for some years now -- so this
 > >handle (a DOI)
 > >
 > >10.1000/170
 > >
 > >can be resolved using a proxy server such as
 > >
 > >http://hdl.handle.net/10.1000/170 or http://dx.doi.org/10.1000/170 or
 > >http://hdl.loc.gov/10.1000/170
 >
 > Interesting.
 >
 > >or in a URI-type syntax as
 > >
 > >hdl:10.1000/170
 > >
 > >which uses the handle protocol directly and which is, not surprisingly,
 > >more efficient for handle resolution,
 >
 > Why is it more efficient? Of course, if the above servers are
 > run as simple proxies that just transform and forward the
 > request, it gets slower, but it should also be possible to
 > do a more coupled implementation that should not be slower.
 >
 > Please note that the DNS lookup overhead inherent in the HTTP protocol
 > is also incurred for an urn solution, if DNS is used to find the
 > resolver for the URN.
 >
 > >but of course requires software
 > >such as a browser extension that understands it, as a URI. To the best
 > >of our knowledge most handle resolution currently goes through one or
 > >another proxy server.
 >
 > Why is there more than one? To share the load? It could be distributed
 > rather easily on the dns level.
 >
 >
 > Regards,   Martin.

Received on Saturday, 13 May 2000 07:25:17 UTC