RE: [xri] Is the behavior correct?

John,

Good catch. You are correct that, by the Redirect and Ref rules in ED06, SEPS in a XRD are NEVER processed if there is a EITHER a Redirect or a Ref at the XRD level. Per your’s and Steve’s suggestions, I am adding an explicit notice to the Redirect and Ref section about this, including that a XRD that includes a Redirect or Ref at the XRD level SHOULD NOT contain SEPs, as they will never be processed and thus can be deceiving to a consuming application.

I will also note your suggestion that if the desired behavior is the FORMER behavior of a xrd:XRD/xrd:Ref element, i.e., that it is only selected if the SEP being sought is not found, then the way to obtain that behavior is to put the Ref in a default SEP.

I’ll forward this offlist to Victor and Kermit to make sure they’ve seen this.

BTW, the project name is spelled “BARX”. I can’t fully explain the acronym on a public email list, but you can fill in the blanks: “Bad ____ Ruby XRI” resolver ;-)

=Drummond

From: John Bradley [mailto:jbradley@mac.com]
Sent: Thursday, October 25, 2007 3:39 PM
To: OASIS XRI TC
Subject: [xri] Is the behavior correct?

I have run some examples through BARKS

First query:

http://xrisoft.net:4000/@ootao*steven?_xrd_r=application/xrds+xml%3Bsep=true&demo=true

We see a ref to the CID of =steven at the XRD level of *steven.

http://xrisoft.net:4000/@ootao*steven?_xrd_t=http://openid.net/signon/1.0&_xrd_r=application/xrd+xml%3Bsep=true&demo=true

This produces a XRD with the CID of =steven not @ooTao*steven.

−

−

<Type select="true">http://openid.net/signon/1.0</Type>

<URI priority="1" append="qxri">https://2idi.com/openid/</URI>

<URI priority="2" append="qxri">http://2idi.com/openid/</URI>

</Service>

</XRD>

I believe this to be correct.

However if we try.

http://xrisoft.net:4000/@ootao*steven?_xrd_t=xri://+i-service*(+contact)*($v*1.0)&_xrd_r=application/xrd+xml%3Bsep=true&demo=true

We get:

−

<XRD>

<Query>*steven</Query>

<ServerStatus code="100">SUCCESS</ServerStatus>

<Status code="100" cid="verified">SUCCESS</Status>

−

<xrd:Service priority="0">

<xrd:ProviderID>xri://!!1003!103</xrd:ProviderID>

<xrd:Type select="true">xri://+i-service*(+contact)*($v*1.0)</xrd:Type>

<xrd:Type match="null"/>

<xrd:Path select="true">(+contact)</xrd:Path>

<xrd:Path match="null"/>

<xrd:URI priority="1" append="authority">http://linksafe-contact.ezibroker.net/contact/</xrd:URI>

</xrd:Service>

</XRD>

The ref is not followed. I think this is a holdover from WD10 where where the ref at the XRD level was not followed if SEP is matched in the XRD.

Should the correct result have been?:

−

−

<XRD>

<Status code="222">The subsegment does not exist</Status>

</XRD>

</XRDS>

This is no Fault of BARKS it is doing what I thought it should be doing before our conversation earlier today.

So is everyone clear that SEPS in a XRD are never processed if there is a ref at the XRD level?

=ve7jtb

xri message