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.

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

xri message