[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Redirect & Ref Processing: Revision #4
I have posted the fourth revision to the Redirect & Ref
Processing proposal at:
http://wiki.oasis-open.org/xri/XriCd02/RefProcessing Notes: 1) Since the proposal is now quite mature, I spent time
organizing the proposal and examples on this page so they are *very close* to the final normative text and
examples that will appear the revised Section 12 of XRI Resolution 2.0 Working
Draft 11 Editor’s Draft 06. This section was named “Reference
Processing” in ED05 and will be renamed “Redirect and Ref
Processing” in ED06. 2) All changes in this proposal (vs. revision #3) are
highlighted by NEW IN REV #4:
REVIEW CAREFULLY. These include:
a) Rules for both Redirect and Ref elements at the XRD level.
b) Consistent use of nested XRDS documents for showing either Redirects or
Refs.
c) Return to ED05-style nesting of XRDS documents, i.e., for either a Redirect
or a Ref, the nested XRDS is only for the actual Redirect or Ref identifier,
and any subsequent XRDs representing additional XRI subsegments are in the
parent XRDS. 3) I added even more examples (and numbered them all), so
hopefully even Victor will be happy ;-) Overall, I like the way the proposal is now logically
consistent throughout. I would highlight that by including a table at the start
of section 12 showing the similiarities and differences between Redirect and
Ref element processing. It would include the following key points: 1) Both are allowed at the XRD level and the Service level.
In both cases, the XRD level results in automatic processing, and the service
level results in processing only if the SEP is selected. 2) A Redirect is for physical redirection between XRDS
documents only, thus it: a) only takes a HTTP(S) URI, b) never restarts
CanonicalID verification, and c) will result in only one additional XRD. 3) A Ref is for logical redirection between XRI authorities,
thus it: a) only takes an XRI, b) always restarts CanonicalID verification, and
c) may result in any number of additional XRDs. 4) Both a Redirect and a Ref product in a nested XRDS
document. The only difference is that the XRDS element will have either a
redirect or a ref attribute, but in both cases, this attribute will contain the
exact value of the source Redirect or Ref element. 5) For a successful resolution chain, the outermost XRDS
document will now always have exactly the same number of XRDs as the QXRI has
authority subsegments (excluding the community root authority). Even if
multiple Redirects or Refs are followed, they will always be represented as
nested XRDS documents, and these do not count towards the XRDs that represent
each authority subsegment resolved. Once more, please do review and post any final feedback to
the list. I plan to start writing this up in ED06 tomorrow, and would like to
hold the “closure discussion” on Thursday’s TC telecon. =Drummond |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]