[XRI] The New Thread

Thanks Ray,

I think you are correct.  I believe some "Standard" sub-scheme  
mechanism needs to be defined.

In my post form yesterday, I asked the question of which standards  
organization should undertake the lead on that work.

I admit the sub-scheme is a term people may not like but I think it  
makes clear for discussion what the general functionality would be.

One of the issues will be the registration issue you point out.

We could re use the URI schemes.

This would give the people who misguidedly  registered URI schemes a  
easy way to convert to using the http: scheme with substrings.

An example.

webdav://docs.example.com/repos  (Konqueror and others)  ===>   http://docs.example.com/dav:/repos

NOTE (From Marty's comments you can see the resistance to using a  
methodology like PROPFIND to discover if a http: scheme URL is a  
webdav mount point , XRI or regular html URI.)

We also had quite novel and interesting suggestion of using DNS names  
for the sub schemes.  This would allow for the discovery of the sub  
schemes properties by retrieving a XRDS document form the host at the  
published domain name.  This would be similar to XRI 2.0 Sec 6  
resolution otherwise known as XRDS Simple.

If we created new TLDs to encode the sub-schemes that is also a  
possibility and has some other interesting properties .

I think we have several good ideas.   They do need to be turned into a  
standard.

Regards
John Bradley
OASIS IDTRUST-SC
http://xri.net/=jbradley


On 17-Jul-08, at 6:59 AM, Ray Denenberg, Library of Congress wrote:

>
> From: "Paul Prescod" <paul@prescod.net>
>> Let me make a concrete proposal.
>> Could the W3C (the TAG? Or someone else?) issue a recommendation to  
>> the
>> effect that URIs of the following form are special:
>> http://xri.example.org/SOMETHING:/@boeing*jbradley/+home/+phone
> .....
>> Once the W3C had issued such a recommendation, the chances of someone
>> minting these URIs by accident would drop
>
> But the problem isn't the risk of someone minting these URIs *after  
> the
> fact* (accidentally or otherwise).  The problem with this approach,
> registering a reserved string for the first URI path component, is the
> possibility that that string is already used.  It's not simply a  
> matter of
> telling everyone in the world "don't ever use this string as the  
> first path
> component of any URI you ever mint in the future".   Rather, you're  
> telling
> everyone they'll have to change every such existing URI. I'm sure  
> nobody is
> contemplating that, so what it means is finding some unique string  
> that
> nobody in the world has ever used (in that part of a URI).  How do  
> you go
> about that? (And not just one - SOMETHING will only be the first,  
> someone
> will subsequently want SOMETHINGELSE, then ANOTHERTHING, and so on.)
>
> --Ray
>
>
>
>