Re: [Lsid-developer] Why use lsidres: and not urn:lsid: as protocol handler?

[Ricardo S. P. <ri...@td...>]

    Hi Sean,

    The social problem, i.e., getting browser developers to come up with 
a solution or standard, seems pretty difficult to solve. But the 
technical aspects seem easier to deal with.

    Below is a suggestion on how to solve the problem (be warned that 
I'm not sure whether I'm serious about it or I'm just being sarcastic... 
will find out after I write it):

1) Someone writes a standard (IETF RFC??) for UPHD: URN Protocol Handler 
Dispatcher. That spec says that:
    a) A UPHD implementation handles urn: as a protocol in web browsers 
in a generic way (as a dispatcher).
    b) All a UPHD does is to find what is the URN namespace (abc: for 
urn:abc:, lsid: for urn:lsid:), find the respective sub-handler 
registered in the system (following well-know rules - see below), and 
dispatch the request to the sub-handler.
    c) There should be well known rules for registration of sub-handlers 
for each browser.
    d) A UPHD must check the presence of other previously installed UPHD 
in the system (using the well known rules defined above). If another 
UPHD is present, the one being installed may provide a choice to the 
user to replace the existing one, or to leave it alone.

2) Then someone provides reference implementations for all major 
browsers as an open source project in SourceForge. To ship any URN 
sub-handler (such as urn:abc:) one would need to ship and install the 
UPHD reference implementation and register his or her own sub-handler 
using the well-known rules defined above.

3) We make a lobby with every single group who is specifying urn: 
schemes to use this solution.


    An example of specs for item (1.c) above would the to mimic the 
Internet Explorer Asynchronous Pluggable Protocol (lsidres: is one of 
such things) registration scheme. In IE all handlers are listed under 
the following registry key:

HKEY_CLASSES_ROOT\PROTOCOLS\Handler

    For example, the lsidres: protocol handler is defined by the 
registry key:

HKEY_CLASSES_ROOT\PROTOCOLS\Handler\lsidres

    There is a key inside it named CLSID which value is the COM class 
GUID of the class that implements the handler:

HKEY_CLASSES_ROOT\PROTOCOLS\Handler\lsidres\CLSID={F6E2AA35-1376-4BF2-907D-4BF81D6CC939}

    A sub handler could use a similar schema where it would use the 
following key:

HKEY_CLASSES_ROOT\PROTOCOLS\UPHDHandler

or

HKEY_CLASSES_ROOT\PROTOCOLS\URNHandler

    The end result would be some registry key like this:

HKEY_CLASSES_ROOT\PROTOCOLS\URNHandler\lsid\CLSID={...}
HKEY_CLASSES_ROOT\PROTOCOLS\URNHandler\doi\CLSID={...}
HKEY_CLASSES_ROOT\PROTOCOLS\URNHandler\hdl\CLSID={...}

    I'm not very sure how this would be implemented in other browsers.

    That could work. If IETF turns down our UPHD RFC, we drop item #1 
and implement only item #2 and wait for the browsers developers to 
implement it properly.

    Cheers,

Ricardo


Sean Martin wrote:

>
> hi Ricardo,
>
> You have indeed identified the reason we had to go with "lsidres"
>
> >In other words, IE and Firefox would need to be extended to handle 
> urn: protocol handler
> >and dispatch the request to the correct sub-handler (urn:lsid, urn:doi,
> >urn:etc:).
>
> Nobody could figure out how to get the browser writers to do this. 
> Whereas registering a protocol handler (lsidres in this case) was 
> already reasonably supported by both browsers. We could of course have 
> registered the "urn" scheme but then we would probably have had to 
> face complaints from other URN NID owners down the line. Not a very 
> satisfying solution I know, but until the browser developers figure 
> out a better way to support extensions the various URI standards, we 
> are somewhat stuck with this compromise.
>
> Kindest regards, Sean
>
>
>
>
>
> *Ricardo Scachetti Pereira <ri...@td...>*
> Sent by: lsi...@li...
>
> 02/22/2006 03:59 PM
>
> 	
> To
> 	lsi...@li...
> cc
> 	
> Subject
> 	[Lsid-developer] Why use lsidres: and not urn:lsid: as protocol handler?
>
>
>
> 	
>
>
>
>
>
>     Hi all,
>
>    Please pardon my lack of knowledge about the URN specs, but is there
> any strong reasons why LaunchPad and Rod Page's Mozilla Extension use
> lsidres: and not url:lsid: as the protocol handler?
>
>    I searched the mailing list archives and also googled around but
> coudn't find the answer.
>
>    Using the urn scheme would make it easy to use LSIDs as links in
> html pages and other documents directly without the need to add the
> prefix lsidres. The donwside is that someone (or some software) would
> need to prevent the various urn schemes from coliding. In other words,
> IE and Firefox would need to be extended to handle urn: protocol handler
> and dispatch the request to the correct sub-handler (urn:lsid, urn:doi,
> urn:etc:).
>
>    Thanks,
>
> Ricardo
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Lsid-developer mailing list
> Lsi...@li...
> https://lists.sourceforge.net/lists/listinfo/lsid-developer
>