Re: Using HTTP Headers to Request Descriptors (was RE: [XRI] Back to XRI)

On Sep 13, 2008, at 5:04 PM, John Bradley wrote:

> XRI resolution also defines HXRI as a way of expressing XRI as  
> http(s): scheme URI via a proxy server.
> This enables you to use https://xri.net/=jbradley in a web  
> application where something may attempt to treat it as a  
> "information resource"

Just a point of rhetoric: may I suggest "treat it [a URI] as naming an  
'information resource'" rather than "treat it as an 'information  
resource'."

In this case, you could say you're using =jbradley to name you, and  
the https: URI to name a metadata document (as httpRange-14 would  
suggest). You might also say that you're also using the https: URI to  
name you, and this dual use is what would contradict "web  
architecture" or more precisely the univocity / no-collisions / no- 
homonyms principle. Now it's clear that you need to decide whether to  
reject univocity (kindly don't) or narrow the meaning of one or more  
URIs (inventing new ones as needed to avoid collisions).

> We are currently working with the TAG understand there contention  
> that "We are not satisfied that XRIs provide functionality not  
> readily available from http: URIs."
>
> [...]


> This is being referred to as a sub scheme or http: URI profile.
>

> Where it gets tricky is not violating the principles of AWWW if the  
> identifier gets used outside of the XRI identifier context.
> If it has its own scheme browsers etc have a known way to deal with  
> it as a known or unknown scheme.
> As a http:scheme URI unless they understand these new sub-scheme  
> rules they will assume it is a URI related to a "information  
> resource".

I don't think browsers care whether something is an "information  
resource" as their behavior is never contingent on making such a  
distinction. I think this is why the 303 hack has such appeal - it  
just works without the browser knowing any better. Other kinds of  
client may care, and perhaps future browsers will (but it's hard for  
me to imagine how). The questions one wants to ask about a resource  
are generally more specific than just asking if something is an IR -  
e.g. is it a poem, or can it be expected to be serviced by some  
particular protocol - and these are going to be answered independently  
of any assessment of whether the thing is an IR.

So I disagree that there is any assumption. The browser is entirely  
guided by the responses it gets from the server, which are interpreted  
operationally, not ontologically.

> Trying to address this leads us to Link headers and 303 redirects.
>
> Where I think we have the largest problem is with XRDS-Simple and  
> some of there use cases to use non sub-scheme URI like http://yahoo.com 
>  as "non-information resources"  while still being a "information  
> resource"  for conventional web browser access.

Agreed - dual use of http://yahoo.com as an IR (which is what the  
httpRange-14 resolution says it is) and something else contradicts  
univocity. But just because a browser ends up showing a page (whether  
via 200 or 303) doesn't mean that it has taken a stand on whether the  
name names any particular kind of thing.

This is my first exposure to XRDS-Simple. What is the relation between  
the XRI and XRDS-Simple efforts - how do their requirements compare,  
and how much do you care about it? Is it implicitly a major part of  
our XRI discussion here on www-tag?

> Perhaps it is just a limitation of http: the protocol that we can't  
> resolve.

Not sure what you're saying - what is "it"? If "it" is univocity, then  
yes, that is a limitation, but I haven't heard anything yet that says  
it can't be overcome (i.e. met). If there is no chance of a change in  
the XRDS protocol's HTTP binding, and it depends on use of CN that  
contradicts univocity, then we may be stuck, but it doesn't sound like  
we're there yet.
>
> At the moment XRDS-Simple is overloading content negotiation.  That  
> isn't working for larger sites due to the obvious caching issues.

> They are currently heading down the road of using a custom header to  
> indicate that Link headers should be included in the response.

That would be unfortunate. Are they thinking of putting the requested  
metadata directly in as many Link: headers as needed, instead of in a  
separate document? How would the metadata be cached?
>
> So to your question we do have a discovery protocol that could be  
> used with XRI in http: form if we formalize a sub scheme.

Sorry, you're referring here to which protocol exactly?

If I understand the XRDS-Simple GET protocol correctly, the difficulty  
is that you want to be able to discover metadata for things named by  
arbitrary http: URIs, and for some reason you want to (a) use HTTP as  
it was meant to be used, (b) use existing HTTP methods, and (c)  
succeed in at most a single round trip. Maybe: (d) also work on URIs  
that name IRs. I don't think these can be satisfied simultaneously  
while following RFC2616; CN fails on (a), URIQA fails on (b), while  
303 and Link: fail on (c), and 303 in practice (but not in principle,  
as David Booth points out) fails on (d).

(The XRDS-Simple HEAD protocol is easier since it's two round trips  
and therefore isomorphic to HEAD/Link: or HEAD/303.)

The use of some new HTTP response status code signaling that the  
metadata is contained in the entity of that response (as opposed to  
being linked) has been suggested, but this won't work for getting  
metadata for IRs and, like URIQA, fails to give a URI to the metadata  
that would facilitate linking, caching, meta-metadata, and so on.  
(Maybe a metadata URI could be supplied via content-location?)

An approximation to meeting (a)-(c) is template caching. Here is a for- 
instance. If we had a common way to express client-side URI  
manipulation rules, then these rules could be delivered somehow,  
cached, and then used to do the original-URI to metadata-resource-URI  
mapping for other URIs matching a common pattern.  E.g. let R = a rule  
that says that to get the metadata URI for a URI of the form http://example.com/xyz 
, insert 'about/' to get http://example.com/about/xyz (for any xyz).  
Rule R could be discovered in a number of ways, for instance: do a GET  
or HEAD of http://example.com/abc, receive a 303 or Link: to http://example.com/about/abc 
, do a second GET that returns metadata for the original object, with  
rule R "hitchhiking" along, i.e. included with the metadata. Now the  
client, knowing R, can use R to go directly to metadata for an object  
with similar URI http://example.com/def without doing a direct GET/ 
HEAD and the 303 or Link: dance.

(The above is based on 'dynamic resource mapping' in http://www.hueniverse.com/hueniverse/2008/09/discovery-and-h.html.)

Having a rule applying to the XRI subscheme would be a special case.

> There is work to do defining how this fits with AWWW in some  
> sensible way.
We've identified URI authority (which prefers *.xri.net to xri.*) and  
univocity (with CN consistency as a special case) as AWWW issues. Just  
to check that I understand - are there any others?
>
> At the moment as you point out the two mechanisms we have been  
> directed to for http: compatibility are:
> 1.  Not in the current http: and only a proposal in the case of Link  
> headers
I think at least one of these difficulties can be overcome.
> 2. New and lacking consciences for 303 redirects.
(consensus?) The new use of 303 has a lot of momentum and seems to be  
harmless. Perhaps any doubts can be addressed or worked around; e.g. a  
server that cared could generate a 303 response containing a Link:  
header - belt and suspenders - to make sure its message got across.
> 3. Still a rough idea in the case of http: sub-schemes
Rough, yes, but I see no impediment so far to smoothing it.

Best
Jonathan

Received on Monday, 22 September 2008 14:38:45 UTC