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