[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Redirect & Ref Processing: Revision #4
Markus, Thanks for catching the cut-and-paste errors
in Ref Example #2 and #3. I just fixed them. That’s why I plan to use these
examples directly in the spec – they will already have been reviewed
closely. As for your idea that a Redirect should
result in an XRD being replaced vs. a nested XRDS document, I agree that would
be okay too. I like the idea that the audit trail could be that resolver would
add a “redirect” attribute to the XRD. We’d specify that this
attribute would NOT be part of the XRD when validating a signature under SAML
trusted res. That approach only works one level deep, though,
i.e., if a Redirect lead to another Redirect (an admittedly corner case), the
nested XRDS document approach can show all of them (each XRDS nested inside the
previous), whereas the XRD replacement + redirect attribute case would only
show one (unless we said you put all the redirect HTTP(S) URIs in the redirect
attribute value, space-separated, which seems kind of clunky). What do others think? =Drummond From: markus.sabadello@gmail.com
[mailto:markus.sabadello@gmail.com] On Behalf
Of Markus Sabadello
On 10/3/07, Drummond
Reed <
Drummond.Reed@parityinc.net> wrote: 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]