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:] 

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.  

 

−

                     <XRD
version="2.0">

<Query>!C5FB.53B6.6E94.824</Query>

<ServerStatus code="100"/>

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

<Expires>2007-10-25T23:06:35Z</Expires>

<ProviderID>xri://=</ProviderID>

<LocalID
priority="10">!C5FB.53B6.6E94.824</LocalID>

<CanonicalID
priority="10">=!C5FB.53B6.6E94.824</CanonicalID>

−

                     <Service
priority="0">

<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>

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

<LocalID>!0000.0000.3B9A.CA16</LocalID>

<CanonicalID>@!5BAD.2AA.3C72.AF46!0000.0000.3B9A.CA16</CanonicalID>

<Ref>=!C5FB.53B6.6E94.824</Ref>

−

                     <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?:

 

−

                     <XRDS
ref="xri://=C5FB.53B6.6E94.824">

−

                     <XRD>

<Query>*C5FB.53B6.6E94.824</Query>

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

<Expires>2007-10-25T23:23:48.000Z</Expires>

<ProviderID>xri://=</ProviderID>

</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