SSSS, /site-meta, and HTTP-based Resource Descriptor Discovery

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

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