[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Handle-info] Lessons from DNS? Whyever not?



Hi:

Following up on the earlier discussions here on a handle URI scheme, I'm
mindful that there are two tricky areas for handle:

    1. Authority component: i.e. hdl://1234/567 or hdl:1234/567

    2. Query component, i.e. hdl://1234/567?type=URL&index=5... or ...

Fragments which are interpreted client-side are probably best left
unspecified.

Querystrings, on the other hand, are interpreted on the server and could
conceivably be restricted to a given syntax. This still seems to be
generally wrong, but there is an undeniable utility begging there: the
ability to access individual fields of a handle record. The problem is does
that place the same requirement on all servers and what level of granularity
would access be specified to.

And, in the back of my mind is this:

    Domain Name System Uniform Resource Identifiers
    http://www.rfc-editor.org/rfc/rfc4501.txt

which more or less specifies

     dns:[//authority/]domain[?CLASS=class;TYPE=type]

Qestion is can one have one's cake and eat it too?

Look at these examples:

    dns:www.example.org.?clAsS=IN;tYpE=A

    dns:www.example.org

    dns:simon.example.org?type=CERT

    dns://192.168.1.1/ftp.example.org?type=A

Since one can direct a handle to any handle server for resolution does it in
fact make sense to distinguish between the name aspect (which is invariant)
and the resolution aspect (which is server dependent)? Could that be a means
of allowing for both hdl: and hdl:// forms, and for allowing for a canonical
querystring syntax?

Some language up front in that document is also worth reading:

    "The URI scheme described in this document focuses on the data stored
   in the DNS.  As such, there is no provision to specify any of the
   fields in the actual DNS protocol.  This is intended so that the URI
   may be used even in situations where the DNS protocol is not used
   directly.  Two examples for this are zone file editors and DNS-
   related configuration files, which may use this URI scheme to
   identify data.  The application would not use the DNS protocol to
   resolve the URIs.

   A limitation of this design is that it does not accommodate all
   protocol parameters within the DNS protocol.  It is expected that,
   for certain applications, a more detailed URI syntax that maps more
   closely to the DNS protocol may be required.  However, such a URI
   definition is not included in this document.  This document specifies
   a URI that is primarily intended to name DNS resources, but it can
   also be used to locate said resources for simple, yet common,
   applications."

Just putting this out for consideration. I can see some merit in this
although haven't thought it all through.

Cheers,

Tony


********************************************************************************   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and 
attachments (if any). No contracts may be concluded on behalf of Macmillan 
Publishers Limited or its agents by means of e-mail communication. Macmillan 
Publishers Limited Registered in England and Wales with registered number 785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
********************************************************************************


_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info