[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]