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: Subproposal for Redirect & Ref processing at the XRD level


While doing the writeup of revision #4 of the Redirect/Ref proposal, it occurred to me that there could in fact be a simple rule for using EITHER a Redirect or a Ref at the XRD level. The rule would be:

 

1) The XRD schema would allow a CHOICE of either zero or more Redirect elements or zero or more Ref elements at the XRD level, but not both (same as at the Service level, except there you have the third choice of using URI element).

 

2) If one or more Redirect elements appears at the XRD level, the resolver MUST process the Redirect, even if sep=false, and before any service endpoint selection if sep=true.

 

3) If one or more Ref elements appears at the XRD level, the resolver MUST process the Ref, even if sep=false, and before any service endpoint selection if sep=true.

 

In both cases, the use case is that the XRDS author wants to manage the entire XRDS document in a different network location. In the first case, the XRDS author wants to specify the different location using a HTTP(S) URI, and does not want to change the CanonicalID or other synonyms. In the second case, the XRDS authors wants to specify the different location using an XRI, and wants to use a different CanonicalID and other synonyms.

 

Now both Redirect and Ref would have very clean and symmetric semantics when they appear at the XRD level, both would result in a nested XRDS document, and both would provide a function that is not available at the Service level, which is automatic processing by the resolver even if sep=false, or BEFORE service endpoint selection if sep=true.

 

This makes so much sense to me that I’m going to go ahead and include it in revision #4 of the Redirect/Ref proposal. Feel free to shoot it down in the meantime ;-)

 

=Drummond

 


From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Tuesday, October 02, 2007 2:02 PM
To: 'Steven Churchill'; 'John Bradley'; xri@lists.oasis-open.org
Subject: RE: [xri] PLEASE REVIEW: Revised Redirect & Ref Processing Proposal

 

Steve,

 

I agree that Redirect is necessary at the service level, because the XRDS author may wish to perform different redirects based on which service is selected.

 

In discussing this with John, the one advantage to also allowing the Redirect element (not the Ref element) also at the XRD level is that the spec would say that if a Redirect appears at the XRD level, the resolver automatically processes the redirect, even if sep=false. (Also, if sep=true, a Redirect at the XRD level would be processed before any service endpoint selection is performed.)

 

However, that said, I’m not married to the Redirect element needing to be at both the XRD and Service levels.

 

Markus, if a Redirect at any level results always in a nested XRDS document (as is now proposed – I’m writing it up), do you still feel strongly it should be at both the XRD and Service levels, or are you willing to live with it at just the Service level?

 

Anyone else who has strong opinions about a Redirect at the XRD level, please do post ASAP. (Again, the current consensus is that Ref is needed ONLY at the Service level, since Ref processing is only triggered by service endpoint selection.)

 

=Drummond

 


From: Steven Churchill [mailto:steven.churchill@xdi.org]
Sent: Tuesday, October 02, 2007 1:22 PM
To: 'John Bradley'; xri@lists.oasis-open.org
Subject: RE: [xri] PLEASE REVIEW: Revised Redirect & Ref Processing Proposal

 

I think keeping the redirect element at the Service level has the most flexibility. And, as John points out, it is tasty and expeditious.

 

~ Steve

 

 


From: John Bradley [mailto:jbradley@mac.com]
Sent: Tuesday, October 02, 2007 8:24 AM
To: xri@lists.oasis-open.org
Cc: Kermit Snelson
Subject: Re: [xri] PLEASE REVIEW: Revised Redirect & Ref Processing Proposal

 

Markus,

 

As I understand it the synonym verification is a way to check the relationship between the XRDS pointed to by the URL and the CID of the XRDS pointing to it.

 

I don't know what a spoofer would gain by pointing to a valid XRDS at the URL as they could always construct a new one at another URL with the appropriate synonym.

 

I don't see it adding much but someone thought it was important perhaps in some other context. So I don't see any harm in the resolver checking other than processing. Likely it will mostly be useful to detect mal configuration, not a bad thing.

 

As Drummond pointed out the simplest case is only having it at the XRD level and replacing the whole XRD with the one from the URL, Exactly like a HTTP redirect.

 

We loose the ability to have the URL selected based on the service.

 

On the other hand thinking about it that may not be the goal of the spec.

 

The use case is to allow people to place there XRDS on a simple web server.

 

The simple case achieves this. Perhaps if someone wants to compose an XRDS from multiple sources we push the responsibility on them. We are keeping up our end. They can have the XRDS static or constricted any way they like on the server. The web server is not in our scope.

 

So I will support the path to the quickest resolution of this point.

 

I need to learn that just because a XRI resolver could do something that doesn't mean that it should do something.

 

73

=ve7jtb

 

 

 

On 2-Oct-07, at 2:11 AM, Markus Sabadello wrote:

 

 

Hmm everything about the Refs sounds fine.

 

But I can't say I like the new Redirect proposal very much. I liked the original idea of it being an equivalent mechanism to HTTP redirects (just like HTML has HTTP-EQUIV), but this would mean:

- Allow it ONLY on the XRD level, not Service, so that it doesn't depend on the sep=true parameter.

- Forget synonym verification (I don't understand what that is for anyway).

- Replace the new XRD, not append it (I especially dislike the idea of having multiple XRDs for a single authority in an XRDS).

 

So that's how I would do it. I don't think it would add complexity, it would be quite simpler. And make it easy to understand the difference between Redirect and Ref. If you see a Redirect on the XRD level, just do an HTTP GET and replace the current XRD. That's it.

 

But my opinion on this is really not very strong; Your proposal makes sense too, and if others want it to be that way, then that's fine.

 



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