Re: Back to XRI

On Tue, Aug 5, 2008 at 4:43 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

>> In order to invoke that extra resolution machinery, it must be
>> possible for client apps to recognize these identifiers when they are
>> used as URIs. This recognition must necessarily happen before
>> resolution, not after.
>
> No, it could just as easily be invoked always in parallel, or only
> upon cache miss, or only upon response failure, ... just as folks
> have done in the past for cache hierarchies, shared annotation
> services, etc.

This, to me, is the crux of the issue. If one of these techniques is
appropriate for the domain, then there is no need for a special class
of URIs. But they all have different resource usage characteristics.
Yes, if there were no latency, CPU were free, bandwidth were free then
it would be fine for Boeing to ask their internal resource identity
server "do you know about this resource?" for every representation
retrieved within their firewall, or to have some kind of shared
annotation database or ... Perhaps it is fine. I'm not one of the
petitioners so I'll leave it to them to say what their resource
utilization requirements are.

>> Therefore the current proposal as I understand it is to treat HTTP
>> URIs in subdomains of XRI.net as XRIs.
>
> I think that proposal completely misses the point of the TAG's objection.
>
> The WWW is the web of interlinked worldwide information.  It has value as
> a function of its interlinking.  If you introduce yet another identifier
> mechanism that takes (mostly) the same set of potential information
> sources but identifies them via a different and mostly incompatible
> set of names, then you have either bifurcated the Web or duplicated the
> Web.

You're right that I do not understand.

Let's say that Boeing implements a policy that every URI within Boeing
is first looked up in their own name resolution server as you
suggested above. Or perhaps they implement a policy that they only do
that for URIs in XML attributes with the name "xri:href". Or perhaps
they implement a policy that they only do that for URIs in documents
in a new MIME type that they invent. Or perhaps there is a whitelist
of URIs to treat differently shared by XMPP. We could imagine many
other mechanisms.

Each of these result in people at Boeing getting different behaviour
from their web client software than people using off-the-shelf
software at their Internet cafe. So in that sense they have bifurcated
the web.

Now my understanding is that none of these triggers is against web
architecture (despite, I believe, bifurcating the web). But if the
trigger is embedded within the URI then it violates the principle of
URI opacity and is at odds with web architecture.

That distinction is the part that I admit to not understanding.

 Paul Prescod

Received on Wednesday, 6 August 2008 00:40:11 UTC