Re: Should the HTTP protocol become "inapropriate"

Hi David,

Comments inline.
On 28-Jul-08, at 7:39 AM, Booth, David (HP Software - Boston) wrote:

>
>> From: Paul Prescod
>> [ . . . ]
>> Is it the position of Tim, Mark and David Orchard that it would be
>> wrong? Dangerous? to define a mechanism for embedding hints for
>> alternate resolution protocols inside of HTTP URIs?
>
> No, it is not wrong.  It is fine to embed hints of any kind in HTTP  
> URIs.  (I realize you didn't ask me, though.)

If it isn't OK to embed hints it should be.

I think David and I are advocating a standard way to embed the hint  
consistent with a "clear chain of authority".  David?
I go farther to call the hint a http: sub-scheme.

>>
>> My opinion is that it is the logical result of the observation that
>> HTTP URIs (backed by HTTP proxies) are better than other URIs on the
>> web in almost every circumstance.
>
> Okay, but I would have said it the other way around: it is one of  
> the reasons *why* HTTP URIs are better than other URIs in almost  
> every circumstance.
>

HTTP sub-schemes would allow the use of non DNS authorities inside the  
http: scheme.

The TLD idea referred to as the booth-bradley proposal by the TAG has  
the advantage of allowing a arbitrarily large number of proxies for a  
single authority resolution protocol.

w3.org.xri and boeing.com.xri could both be recognized by client  
applications as equivalent proxy gateways for XRI.

This is required work independent of XRI.   The question is who will  
do this work to refine http:?

If there is a standard XRI and others will make use of it.  It adds  
functionality to XRI and HTTP.

Best Regards
John Bradley
OASIS IDTRUST-SC
http://xri.net/=jbradley
五里霧中

>
>
>
> David Booth, Ph.D.
> HP Software
> +1 617 629 8881 office  |  dbooth@hp.com
> http://www.hp.com/go/software
>
> Statements made herein represent the views of the author and do not  
> necessarily represent the official views of HP unless explicitly so  
> stated.
>

Received on Monday, 28 July 2008 16:10:07 UTC