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:
[mailto:] On Behalf
Of Markus Sabadello
Sent: Wednesday, October 03, 2007
5:52 AM
To: Drummond Reed
Cc: ; John
Bradley; Kermit Snelson;
Subject: Re: [xri] Redirect &
Ref Processing: Revision #4
What I generally like is the idea that for every subsegment resolved, there's
exactly one XRD in the XRDS, no matter how many Refs and Redirects occur.
I think I'd still prefer Refs only at Service, and Redirects only at XRD level.
I know that would be less powerful than having both elements at both levels,
but simpler to understand. I also still think that for Redirects it would be
better to simply replace the current XRD with the one you retrieve from the
Redirect. It just feels strange to have a nested XRDS here, because a) no XRI
gets resolved, and b) the XRDS can't contain more than one XRD anyway. If you
want a way to "track" what has happened, well one idea would be to
put your "redirect" attribute on the new XRD instead of a nested
XRDS.
But I'll think about this a bit more before the Thursday call, maybe I come to
the conclusion that your proposal is smarter :)
I'm not sure I understand the Ref example #3. It seems that two XRDs are
missing and that *b and *c never get resolved?
And in Ref example #2 and #3 the <Ref>s are incorrectly closed with
</Redirect>.
Markus
On 10/3/07, Drummond
Reed <
> 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
