- From: Jonathan Rees <jar@creativecommons.org>
- Date: Mon, 22 Sep 2008 10:37:57 -0400
- To: John Bradley <john.bradley@wingaa.com>
- Cc: www-tag@w3.org, Drummond Reed <drummond.reed@cordance.net>
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