Re: [xri] SSSS, /site-meta, and HTTP-based Resource Descriptor Discovery

[Nat Sakimura <n-sakimura@nri.co.jp>]

Hi Drummond,

For "designate their own base URI for XRI resolution",
what would be the security implication?

Or, are you suggesting it for community root?

=nat

--------------------------------------------------
From: "Drummond Reed" <drummond.reed@cordance.net>
Sent: Saturday, January 17, 2009 5:56 AM
To: "Sakimura Nat" <n-sakimura@nri.co.jp>; "'XRI TC'" 
<xri@lists.oasis-open.org>
Cc: "'Eran Hammer-Lahav'" <eran@hueniverse.com>
Subject: RE: [xri] SSSS, /site-meta, and HTTP-based Resource Descriptor 
Discovery

> Nat,
>
> I didn't respond to this email right away because I wasn't quite sure what
> you were asking. In re-reading it, I think the answers to your questions
> are, "Yes". The examples look right to me.
>
> With SSSS 
> (http://wiki.oasis-open.org/xri/XriThree/SuperSimpleSepSelection),
> I agree that XRI 3.0 resolution should specify either $xrd (+xrd may also
> work, but specs can only specify $ XRIs) as the type for XRDs that can be
> used to select them.
>
> Also, last week, after reading HRDD draft 00 closely, I sent Eran an email
> asking him something similar, i.e., can't we (the XRI TC) specify that 
> sites
> can use /site-meta to designate their own base URI for XRI resolution
> services? In other words, instead of http://xri.net, or http://*.xri.net,
> having to be the base URI for all XRIs, a site like http://example.com 
> could
> declare that the base URI for its XRI resolution services was
> http://xri.example.com using the following /site-meta entry:
>
> <metadata>
>   <meta href="http://xri.example.com/";
> rel="http://oasis-open.org/xri/xri-base"/>
> </metadata>
>
> Of course, if we registered xri-base with IANA as a rel-type, we could
> shorten it to:
>
> <metadata>
>   <meta href="http://xri.example.com/"; rel="xri-base"/>
> </metadata>
>
> Thoughts?
>
> =Drummond
>
>
>> -----Original Message-----
>> From: Nat Sakimura [mailto:n-sakimura@nri.co.jp]
>> Sent: Wednesday, January 14, 2009 5:23 PM
>> To: XRI TC
>> Cc: Drummond Reed; Eran Hammer-Lahav
>> Subject: [xri] SSSS, /site-meta, and HTTP-based Resource Descriptor
>> Discovery
>>
>> Hi. Looks like this message did not get through, so I am posting again.
>>
>> =nat
>>
>> ------------------------------------------
>>
>> In SSSS, <type> seems to be able to accommodate native XRIs such as
>> +contact.
>>
>> Is that right?
>>
>> Are we going to define something like +xrd so that the URI for the XRD of
>> an
>> abstract resource
>> http://xri.net/=nat would be http://xri.net/=nat/+xrd ?
>>
>> Or, do we always have to do two round trips so that we can make use of
>> link-header, link element, or /site-meta?
>> In case of /site-meta, what would be a good practice to find out the XRD
>> of
>> http://xri.net/=nat via /site-meta?
>> I suppose it is going to be asking for http://xri.net/site-meta and it
>> includes a template like
>>
>> <metadata>
>>    <link-template template="http://xr.net?xrdof={%uri}";
>>         rel="describedby"
>>         type="application/xrd+xml"
>>         scheme="http https" />
>> </metadata>
>>
>> Is it possible to define a /site-meta like below as well?
>>
>> <metadata>
>>    <link-template template="{%uri}/+xrd"
>>         rel="describedby"
>>         type="application/xrd+xml"
>>         scheme="http https" />
>> </metadata>
>>
>> Then, for http://xri.net/, as long as /site-meta cache is valid,
>> one can just ask for http://xri.net/=nat/+xrd for my XRD, so it will
>> in effect same as the first paragraph of this mail.
>>
>> To be compliant to XRI 2.0, the /site-meta may look like:
>>
>> <metadata>
>>    <link-template template="{%uri}?_xrd_r=application/xrds+xml"
>>         rel="describedby"
>>         type="application/xrd+xml"
>>         scheme="http https" />
>> </metadata>
>>
>> =nat
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>