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

[John Bradley <jbradley@mac.com>]

Thanks Markus,

I confused the one level deep with stopping processing.  My bad.

So a ref or redirect would be followed in the redirect starting the process over

If you can put a ref in a default service then I agree the need for the ref at the XRD level is edge case.  (I use ref in the I want the target CID sense.)

A client could always do multiple queries or use its own custom resolver if it wanted to get something out of some XRDS in a path when not doing service selection.

I have no idea what that would be.  I suppose thats why people can always create there own resolver.  

We cant cover ideas we haven't had.  

That is also what 3.0 is for if there is demand.

73

=ve7jtb

On 4-Oct-07, at 1:57 AM, Markus Sabadello wrote:

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.

Markus

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

Drummond

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.

73

=ve7jtb

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

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
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>.

Markus

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