RE: [xri] Backtracking

Les, welcome back. You should give a close read of ED06 first. While you were gone a huge amount of work went into coming to consensus on the rules for both Redirect and Refs. It involved a very intense week of dialog among all the active editors and implementers.

Read section 12, Redirect and Ref Processing, and study the new flowcharts closely – they were completely redone to reflect this new Redirect and Ref architecture.

A key summary of the rules:

1) At the XRD level, an XRD can contain EITHER Redirects or Refs, but not both.

2) At the Service level, a SEP can contain a CHOICE of URIs, Redirects, or Refs (all zero-or-more), but only one of the three types.

3) Processing of EITHER a Redirect or Ref ALWAYS results in a nested XRDS document (if XRDS is the return type), even if it is an error or a dead end.

4) A Redirect or Ref at the XRD level is ALWAYS followed immediately, before the resolver does anything else, including SEP selection. This is new, and it means that SEPs in an XRD that has EITHER a Redirect or Ref at the XRD level are ignored.

5) A Redirect or Ref at the Service level is only followed if it is the selected SEP. As with before, you can always put either a Redirect or Ref into a default SEP that’s chosen if no other SEP is chosen (this would emulate the WD10 functionality of a Ref at the XRD level).

6) Backtracking currently works at all levels (John just posted a message about this).

It’s a lot to digest, but so far folks are happy with it, as it finally gives us a uniform set of rules across all use cases.

=Drummond

From: Chasen, Les [mailto:les.chasen@neustar.biz]
Sent: Thursday, October 25, 2007 6:01 PM
To: jbradley@mac.com; xri@lists.oasis-open.org
Cc: ksnelson@subjectivity.com; Tan, William
Subject: Re: [xri] Backtracking

I am not sure when this change came about. REFs should only be followed in the search of a service whether at the xrd level or service level.

Drummond, in one of you last emails you indicate that a ref and a redirect at the xrd level have the same behavior in that it is followed without inspection of the local SEPs. This is fine for redirect but not ref. Ref should only be followed if the service being sought is not found.

--------------------------
http://xri.net/=les.chasen

----- Original Message -----
From: John Bradley <jbradley@mac.com>
To: OASIS XRI TC <xri@lists.oasis-open.org>
Cc: Kermit Snelson <ksnelson@subjectivity.com>; Tan, William
Sent: Thu Oct 25 20:38:42 2007
Subject: [xri] Backtracking

Reading the spec 11.5 and looking at the flowcharts we now have
backtracking for refs at the XRD level.

For these XRD level refs we iterate through refs and redirects in
priority order.

My question is what causes backtracking. As we have not moved to SEP
selection at his point, is success just returning the XRD?

I see and completely agree on backtracking if the XRD is not returned.

However the spec now indicates that we move to SEP selection once the
XRD is returned and if the SEP is not found we backtrack to the next
ref in authority resolution.

Before we added refs to SEPs this perhaps made more sense.

I prefer the notion of doing this with SEP refs:

1. authority resolution and finding the XRD,
2. Service Selection,
3. Iterating through authority resolution and SEP selection for each
ref in priority order.

If we backtrack from SEP selection into authority resolution I think
it increases implementation complexity.

So we can leave the current behavior and backtrack if no SEP is
found, or change it to only backtrack if no XRD is found.

I am happy with the backtracking on the SEP refs I think that makes
sense.

I will contribute a clarification for 11.5 depending on what behavior
people want.

I particularly would like Kermit and Wil's opinions.

I can live with it ether way as long as its unambiguous.

xri message