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:] 

Sent: Tuesday, October 02, 2007
2:02 PM

To: 'Steven Churchill'; 'John
Bradley'; 

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:] 

Sent: Tuesday, October 02, 2007
1:22 PM

To: 'John Bradley';


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:] 

Sent: Tuesday, October 02, 2007
8:24 AM

To: 

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.