OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xri] Is the behavior correct?



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




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


I have run some examples through BARKS


First query:


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



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


                     <XRD version="2.0">


<ServerStatus code="100"/>

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



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




I believe this to be correct. 


However if we try.



We get:




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

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





                     <xrd:Service priority="0">


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




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



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






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?






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]