Re: Should the HTTP protocol become "inapropriate"

Comments inline.

On 29-Jul-08, at 7:55 AM, Booth, David (HP Software - Boston) wrote:

>
>> From: Prescod [mailto:prescod@gmail.com]
>>
>> On Mon, Jul 28, 2008 at 7:39 AM, Booth, David (HP Software - Boston)
>> <dbooth@hp.com> 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.)
>>
>> Can you be more specific about "hints of any kinds?" Do you believe  
>> as
>> I do that that there must be an orderly mechanism for recognizing and
>> processing those hints? e.g. a browser vendor could not declare that
>> any URI that embeds the path /netscape/ should be resolved at
>> netscape.com rather than on the host specified in the URI.
>
> Correct.  I guess I should have been a little clearer.
>
> There must be a clear chain of authority for interpreting the URI.   
> The chain of authority starts with the URI (or IRI) spec itself.   
> Effectively, the URI (or IRI) spec delegates authority to the  
> scheme.  In the case of the HTTP scheme, the HTTP scheme effectively  
> delegates authority to the domain name owner, who in turn may choose  
> to delegate authority for some sub-spaces of its URI space.  So for  
> example, the owner of foo.example could delegate authority to dbooth  
> for all URIs in http://*.dbooth.foo.example/* or all URIs in http://foo.example/dbooth/* 
>  .  But Netscape could *not* delegate authority for interpreting all  
> URIs that match http://*/netscape/* because Netscape does not own  
> all of those URIs.
>
> Basically, a URI owner may establish any conventions it wishes for  
> URIs in its own URI space, provided those conventions do not violate  
> the specs in the chain of authority.  For example, an HTTP URI owner  
> could not establish a convention saying that a 404 status code means  
> "document found, here it is" and a 200 status code means "no  
> document found".  But it is fine to (non-destructively) layer  
> additional semantics on top of existing semantics, which is what the  
> XRI folks would be doing if they established a convention like  
> http://*.xri.net/* for XRIs, and those URIs can be used both with  
> the HTTP protocol and with their special XRI protocol.
>
>>
>> I believe that the three current proposals are:
>>
>> * use the most specific bit of the domain name as a way of
>> triggering hinting
>
> That would be fine if the owner of that URI space chooses to  
> establish that convention.
>
The one downside of this is that protocol proxy gateways require a  
registration step or something special done in DNS as I have proposed  
elsewhere.

The sub schemes being TLD or domain names are administered by ICANN so  
no new registry is needed.
The documentation for a sub-scheme can be published at the domain in  
question in some agreed upon way.

>>
>> * use the least specific bits of the domain name
>
> That would also be fine if the owner of that URI space chooses to  
> establish that convention.

This is convenient in that it allows multiple proxies without  
registration.  The downside is that it confers special meaning on a  
host name and can have an impact on people who don't want to  
participate in the sub-scheme.

Why should someone tell me that xri or xmpp is a reserved host name.    
I can see this leading to all sorts of great.

It is equivalent to saying that part of the http protocol will only  
apply to hosts named www.

Yes XRI 2.0 resolution Sec 11.2 http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cs01/xri-resolution-V2.0-cs-01.html#_Toc192004447 
   states:

To make this syntax as simple as possible for XRI-aware processors or  
search agents to recognize, an HXRI consists of a fully qualified HTTP  
or HTTPS URI authority component that begins with the domain name  
segment “xri.

This was intended as a compliment to a URI scheme for XRI and not a  
replacement.

This approach if generalized to other sub schemes requires a new  
registry of reserved host names.

For XRI as a one off it is not the end of the world.

As a general approach it sucks big time!
>
>
>>
>> * invent a new convention in paths like /foo:/ which would allow the
>> hint to be orthogonal to the HTTP domain
>
> That would *not* be okay to use as anything more than a guess, just  
> as observing a .html at the end of a URI must not be used as  
> anything more than a *guess* of the media type that might be  
> returned.  The MIME type indicated in the HTTP response is  
> authoritative:
> http://www.w3.org/2001/tag/doc/mime-respect-20060412
> And the URI owner does *not* have the authority to change that.
>
>
This approach sucks more, if generalized.
Sorry ARK people.

I have seen comments in other forums that we are trying to "Replace  
the IETF"

I want to point out that TAG issue-50 recommends that non DNS  
resolution protocols use http: for addressing.
This is not something coming from XRI, openID or oAuth communities.

If at the end of the day we decide that AINA assigned URI schemes are  
the cost effective and preferred way to achieve the specified   
functionality for non http: protocols,  it will require a lot less  
editing of the XRI specs.

If people out there believe that http: sub-schemes are a circumvention  
of the IETF and a bad and harmful thing to architecture of the internet.

Please say so!

Personally I am moving from a position of URIs exist for a reason and  
non http protocols should get a registered scheme from IANA, to one  
where I am starting to see some advantages to having a proper http:  
sub-scheme mechanism.

I don't know that we are at a final conclusion on that issue.

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