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

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]