[OpenID] W3C TAG recommends against XRI

[Nat Sakimura]

Actually, I was backtracking from [3].

The basis for [3] seemed to be [2]. Essentially, this is the topic (3)
in my previous mail.
It essentially says:

P1. Both XRI and HTTP URI both follow the pattern of an administrative hierarchy
      followed by a path.
P2. XRI is intended to produce the persistance, but PROPERLY
ADMINISTERED http uri
      would have the same effect.
P3. Therefore, xri scheme is not necessary and can be replaced with http:.

The point P2 actually seems to be suggesting a transformation
something in line of

   replace xri:// to http://xri.net/

together with announcing that xri.net will never reuse the path if it
starts from "!".
This actually is what the proxy resolver is doing in the actual
implementation, so is very valid especially for the adoption purpose.

However, the sentiment of the TC, as I understand, was what I wrote in
my previous mail on topic (3). i.e.,: (paraphrasing...)

It probably would be inappropreate to use http: scheme for non-http
use cases as it may cause confusion among people since it will not be
clear if it is an abstract one or concrete one by looking at it. xri:
is supposed to be an abstract schema which will be cast onto specific
protocol schema given a context. Introducing new scheme will cause
less confusion, that it may not be an http accessible resource.

So, YES. Technically, we could reuse http scheme, but in considration
of human factors in it, TC thought it would be better to introduce a
distinct unused scheme, xri:.

Second issue that TC had with this approach was very akin to OpenID
reuse problem.
PROPERLY ADMINISTERED is actually rather hard in the real world in the
long run.

OpenID reuse problem may be a problem for a big ID providers, but is a
more serious problem for a person with his own domain or something
like that. OK., if he is PROPERLY ADMINISTERING it, this OpenID reuse
problem will never happen, but can we count on it?

The problem the XRI TC thought of is quite similar to it. Suppose we
decided to use a convention that any domainame that starts from xri
and path part starting by '!' is persistent. That may be technically
workable. But can we count on it? Maybe not. This is another human
factor.

(Also, there were some consideration on the multilingualization as
well. We wanted to write multilingual string in both authority and
path part safely, but doing that makes the string invalid http url,
but this may be a separate issue than an introduction of new scheme.)

=nat

On Fri, May 23, 2008 at 10:47 AM, Christopher St John
<ckstjohn at gmail.com> wrote:
> On Thu, May 22, 2008 at 8:30 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>> I think Drummond will post a note on this, which is more authoritative
>> than mine, but I will post mine in the mean time.
>>
>> Their concerns, I think, are as follows:
>>
>> 1) xri: is not registered at IANA
>> 2) xri resolution requires at least two round trip. One to get XRDS, and
>>    another to get the real resource. This is a waste, and should be
>> done in single trip.
>> 3) We should reuse the existing scheme and http: should suffice instead of xri:
>>
>
> Actually, those weren't statements, but requests for
> clarification (minus the "this is a waste" part, which
> was not part of the w3c response). See [1].
>
> The actual reasons are here[2], with sort of an overview
> and the offical conclusion here[3].
>
> To summarize (badly. go read the originals) you can pretty
> clearly do it all with http, so there's no need for xri.
>
> I'm not an unalloyed fan of the w3c process, but they do
> have some pretty good technical people and the reasoning
> expressed in the response appears to be sound.
>
> -cks
>
>
> [1] http://lists.w3.org/Archives/Public/www-tag/2008Feb/0009.html
> see the paragraph starting "if you could clarify"
>
> [2] http://lists.w3.org/Archives/Public/www-tag/2005Apr/0076.html
>
> [3] http://lists.w3.org/Archives/Public/www-tag/2005Apr/0095.html
>
>
> --
> Christopher St. John
> http://artofsystems.blogspot.com
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/