Re: Boeing XRI Use Cases

Hi Henry,

Thanks for the input.

Sorry it had to do some traveling so just got to look at http://tools.ietf.org/html/draft-kunze-ark-15

I do see some parallel between ARC and the HXRI form of XRI.

I do see a need to preserve the ability of a client application to  
determine if a particular html: scheme URI can be converted to a XRI  
for processing.

In ARC the convention seems to be to prepend the path with ark:  as  
you call it a ARK label.

Would you propose that we adopt the same convention for XRI?

http://hxri-proxy.example.com/xri:/@test*jbradley/+phone/+home
\_____________________/ \__/\_____/\_____/\___________/
        (replaceable)                       |            |          
|                XRI Path
                 |                           XRI  Label    |         |
                 |                                                   
|      XRI Community assigned Subsegment
    HXRI Proxy                                           |
                                                        GRS assigned  
Authority Subsegment


Please excuse my bad ascii art.

This is not dissimilar to what we are discussing for HXRI.

Using xri: in the path is a new proposal.   David and I have been  
discussing using the domain name to distinguish the HXRI.

In some ways this might require the smallest change to the existing  
spec.

How do people feel about this.  If we add an extra slash after the  
colon it looks suspiciously like a URI scheme with a http:  authority  
stuck on the front.

Using the HXRI syntax I think that ARK's functionality could be  
entirely expressed in HXRI.   This is from only an initial read of the  
spec.

It would be an interesting discussion to see if HXRI is a full  
superset of ARK.

I am in no way proposing to supplant ARK with HXRI.

Interesting food for thought.

Best Regards
John Bradley
OASIS IDTRUST-SC
http://xri.net/=jbradley
(look HXRI form, see I can change:)

On 15-Jul-08, at 12:27 PM, Henry S. Thompson wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mark Baker writes:
>
>> If you're trying to extend the Web in a way that requires providing
>> license to agents to extract information from URIs - which appears to
>> be a key part of the functionality XRIs are trying to provide (see
>> 1.1.1 of xri-syntax) - then you need a new URI scheme.
>
> I want to be sure I'm not mistaken to focus on the word 'agent' in the
> above.  I take it we agree that it's perfectly alright for a _server_
> to extract information from http: URIs, in particular to treat the
> path (or 'hierarchical part') as other than a literal path through a
> hierarchical storage medium.
>
> I guess where this gets tricky is when the _minters_ of URIs start
> relying on authority delegation in the path.
>
> Consider the ARK proposal (which I have always held up as a model of
> how to use http: URIs to address requirements similar to many of the
> requirements on XRI) [1].
>
> It offers an approach in which e.g.
>
>      http://loc.gov/ark:/12025/654xz321
>      http://rutgers.edu/ark:/12025/654xz321
>
> identify the _same_ object.  Implicit in the overall proposal is the
> proposition that the above example URIs were minted by people other
> than the owners of the domain names they begin with.  The minters
> _are_ expected to be the owners of the subsidiary authority identified
> by 12025 in the above URIs, and it only makes sense for them to do so
> if they have an agreement in place with the owners of rutgers.edu and
> loc.gov to serve and/or proxy to representations as specified by the
> ARK RFC, which gives them a kind of second-hand ability to mint URIs.
>
> Are you happy with that kind of design?
>
> ht
>
> [1] http://tools.ietf.org/html/draft-kunze-ark-15
> - --
>       Henry S. Thompson, School of Informatics, University of  
> Edinburgh
>                         Half-time member of W3C Team
>      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131  
> 650-4440
>                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
>                       URL: http://www.ltg.ed.ac.uk/~ht/
> [mail really from me _always_ has this .sig -- mail without it is  
> forged spam]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFIfPoKkjnJixAXWBoRArN9AJ9ylfYO8G/49J0Bp5iRYeYibcgi4QCfU+kS
> OxNOusJ3HoYEqxK5RQAyUAM=
> =VQUO
> -----END PGP SIGNATURE-----
>