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

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 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.

This is the same for all URI schemes.


>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

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 hard
>to enforce and is also why the Handle Proxy Syntax is (probably 'forever')
>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 protocol,
>while http relies on TCP for each URL resolution.
>c) handle protocol allows shared network resources (e.g. tcp channel) among
>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 and
>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 Saturday, 13 May 2000 07:25:51 UTC