OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xri] Redirect & Ref Processing: Revision #4

Hmm no I wasn't suggesting that Ref / Redirect processing should stop after following one. On the contrary.

So Drummond is right when he says my "replacement" proposal works only one level deep.

My proposal was just aimed at getting XRD Redirects as close as possible to HTTP redirects, which would mean Redirect only at XRD level and without nested XRDS.

Like you I also don't see much use for a Redirect at service level. And not much use for a Ref at XRD level.


On 10/3/07, John Bradley <jbradley@cogneto.com> wrote:

I didn't think that ether a ref or redirect would be allowed in the replacement XRD.  

The behavior is replace and stop processing, as I understand it.   So I see Markus's point in the case of a redirect as it can not be arbitrarily deep.

I am OK with that as long as the redirect attribute is added to the XRD.

There is more flexibility having the redirect in the service level as well. 

On the other hand I suspect that no-one will ever use it,   I am more than fine having it at the XRD level only in 2.0.

If there is a demand for redirects at the service level then it can be added to 3.0.  if necessary. 

I am in favor of the shortest path to resolving the point.


On Oct 3, 2007, at 9:01 AM, Drummond Reed wrote:



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?




From: markus.sabadello@gmail.com [ mailto:markus.sabadello@gmail.com] On Behalf Of Markus Sabadello
Sent: Wednesday, October 03, 2007 5:52 AM
To: Drummond Reed
Cc: xri@lists.oasis-open.org; John Bradley; Kermit Snelson; andy.dale@ootao.com
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>.


On 10/3/07, Drummond Reed < Drummond.Reed@parityinc.net > wrote:

I have posted the fourth revision to the Redirect & Ref Processing proposal at:






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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]