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