W3C home > Mailing lists > Public > uri@w3.org > May 2000

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

From: Sam Sun (@sun2) <(@sun2)>
Date: Thu, 18 May 2000 16:27:59 +0900
Message-Id: <>
To: uri@w3.org

When I said using "hdl:<handle>" is more efficient than using
"http:<proxy-server>/<handle>", I'm not comparing the syntax, but the
protocol operations underneath each URI scheme. The "hdl" URI uses the
handle protocol, which is more efficient and secure than "http" protocol for
simple name resolution. For example, "http 1.1" doesn't supports UDP, nor
provides secured name resolution. And its encoding isn't as efficient.
Besides, the "http" URI relies on DNS, which has its own problems regarding
internationalization and security. I also won't say "the general tendency is
to separate access and editing even for http". It more looks like a
limitation of the current implementation. T. Berners-Lee in his book
("weaving the web") suggested that he originally saw the web used for both
access and editing. It just didn't get implemented that way. Editting allows
users to access and manage shared resources as those on their local machine,
which I think is a nature step forward.

On the other hand, when efficiency and security is not under consideration,
using "http:<proxy-server>/<handle>" may not be a bad choice. I guess it all
depends on the application.

I'm not sure it's appropriate to drive the discussion into details of the
handle system, or it might be better to discuss it off the mailing list
(which I'm not a subscribed member). If you are interested, you may consider
visit our website at http://www.handle.net. We have just released a Java
version of the handle system, along with the source code. Your comments are
very much appreciated...

Best regards, Sam

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

 > Hello Sam,
 > Many thanks for your info. Some comments below:
 > At 00/05/12 14:19 -0400, Sam Sun (@sun2) wrote:
 > >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:
 > >These suggest that,
 > >
 > >1)  Handles can be resolved directly from handle aware applications, or
 > >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.
 > >like sending email. One can send out email using <email-address>
 > >Or he can use the email URI syntax, like mailto:<email-address>, from a
 > >web-browser.
 > This is the same for all URI schemes.
 > >2) Each handle URI syntax definition utilizes a different interface to
 > >handle system. Personally, I would suggest using "hdl:" syntax which is
 > >efficient
 > Why is the syntax more efficient? It's shorter than the others,
 > but is that so important?
 > >and offers the security not offered by any of the others.
 > How does syntax offer security? You say that each syntax is
 > related to a different interface, but that's not sure. For
 > example, if I had to implement hdl: quickly, I'd probably
 > just convert it to the http:// proxy syntax and hand it
 > off to a http resolver, and so on.
 > >However,
 > >this would need client to install the handle system resolver, which is
 > >to enforce and is also why the Handle Proxy Syntax is (probably
 > >used.
 > If we assume this is used 'forever', how much sense does it make
 > to work on deploying the others? Being able to hand out URIs
 > that work for everybody seems pretty much the most important
 > thing, doesn't it.
 > >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
 > >while http relies on TCP for each URL resolution.
 > >c) handle protocol allows shared network resources (e.g. tcp channel)
 > >multiple requests.
 > Same with HTTP/1.1.
 > >d) handle protocol does not use or rely on DNS. There's no inherited
 > >overhead as http does.
 > If done correctly, you only get that overhead for the first request;
 > for bulks of requests, it's negligible.
 > >e) handle protocol allows secured name resolution without having to
 > >establish any SSL session beforehand. It also defines an access control
 > >administration model that allows handle and handle values to be managed
 > >directly.
 > This is the editing side, if I understand correctly. The Web has
 > 'editing' methods in HTTP PUT and POST. However, the general tendency
 > is to separate access and editing even for http, and it's therefore
 > not a problem if this is done for handles, too.
 > The above points are all advantages when the protocol is in
 > high and wide use. But the Web and HTTP show that efficiency
 > is not that important overall. For an occasional use in a browser,
 > the actual advantages are not that important, but the work to
 > implement all the protocol features is a serious barrier to
 > adoption.
 > This seems to suggest the following:
 > - Continue to use the handle proxy, and make sure it works
 >    as efficiently as possible, and take all the necessary
 >    steps to make sure that this address is established and
 >    guaranteed permanently.
 > - Use the http: proxy address as the 'handle uri', in all
 >    relevant (Web-related) places.
 > - Work on special tools for updating/bulk access/... that
 >    can be deployed easily.
 > - Make sure special tools understand the handle proxy address
 >    and may be able to use a special protocol instead of http
 >    when they see it.
 > Regards,   Martin.
Received on Thursday, 18 May 2000 03:28:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:01 UTC