Ending proxy resolver nightmares

["Drummond Reed" <drummond.reed@cordance.net>]

Victor has an interesting point in his "proxy resolver nightmares" thread.
The main additional requirement we have in XRI 2.0 CD02 is to define proxy
resolution so that it can return a 3xx redirect for an HXRI to a non-XRI
aware browser. That's why we had to define service endpoint selection. Of
course at the other end of the spectrum it is trivial for a proxy resolution
server to return an XRDS document.

So I believe we have complete consensus about the two "ends" of the proxy
resolution spectrum: returning either an entire XRDS document or a single
URI. Where we don't have consensus about is a "mid-point" of returning the
results of service endpoint selection in a richer form than a single URI.

So option #1 to consider on this afternoon's 4PM call devoted to this
subject is to simply punt on defining any midpoint in XRI 2.0.

Option #2 would be to pick a "clean" midpoint that we can all agree on,
i.e., one that, like the two other endpoints (XRDS/everything or URI/one
thing) is something that we've already defined and that we don't have to
create any special rules for.

If we apply this logic, it strikes me that there is one clean midpoint that
we might all be able to agree on: returning just the final XRD. In fact we
could follow a simple rule consistent with the rest of XRI resolution: if
you ask only for authority resolution and want the final XRD back, you get
just the final XRD, with no other processing. If you ask for SEP selection
and want the final the XRD back, you get just the final XRD with just the
SEP(s) that match the input criteria, with no other processing.

Put into a formal proposal, this would be:

1) VALUES OF _XRD_R (RETURN) PARAMETER:

xrds		Return full XRDS
xrd		Return final XRD only
uri		Return highest priority URI of selected SEP only

Note: we might want these values to simply be content types just like the
_xrd_a and _xrd_m parameters. In that case the values would be:

application/xrds+xml
application/xrd+xml
text/uri-list	(see http://www.rfc-editor.org/rfc/rfc2483.txt, section 5)

2) RETURN FROM PROXY RESOLUTION WHEN _XRD_R PARAMETER IS SPECIFIED:

a) xrds/SUCCESS: the full XRDS document with content type
"application/xrds+xml" or "application/xrds-saml+xml" with Status of the
final XRD = SUCCESS. If SEP selection was requested, the final XRD will be
filtered to contain only matching SEPs. If SEP selection is not requested,
the final XRD will not be filtered. NOTE: SEP SELECTION MAY USE ANY CONTENT
TYPE (SEE BELOW).

b) xrds/FAILURE: the full XRDS document with content type
"application/xrds+xml" or "application/xrds-saml+xml" with the Status of the
final XRD = error message.

c) xrd/SUCCESS: ONLY the final XRD document with content type
"application/xrd+xml" or "application/xrd-saml+xml" with Status of the final
XRD = SUCCESS. If SEP selection was requested, XRD will be filtered to
contain ONLY matching SEPs. If SEP selection is not requested, XRD will not
be filtered. NOTE: SEP SELECTION MAY USE ANY CONTENT TYPE (SEE BELOW).

d) xrd/FAILURE: ONLY the final XRD document with content type
"application/xrd+xml" or "application/xrd-saml+xml" with the Status of the
final XRD = error message.

e) uri/SUCCESS: a string with content type "text/plain" containing the
highest priority URI of the highest priority SEP.

f) uri/FAILURE: a string with content type "text/plain" containing the error
code followed by a space followed by the error context string.

3) RETURN FROM PROXY RESOLUTION WHEN _XRD_R PARAMETER IS NOT SPECIFIED:

a) SUCCESS: 3xx redirect to highest priority URI of highest priority
matching SEP, with the content type of the redirect.

b) FAILURE: error message returned as plain text or HTML.


*** NOTE ABOUT CONTENT TYPE AND SEP SELECTION ***

This addition of _xrd_r parameter solves a longstanding issue in XRI proxy
resolution architecture: until now, we have overloaded the _xrd_m parameter
to specify two different things:

1) The content type being requested from the proxy resolution service.

2) The media type of a request service endpoint (SEP).

That means you can't both:

a) request an XRDS document returned from a proxy resolution server, and

b) request any type of SEP selection EXCEPT "application/xrds+xml" or
"application/xrds-saml+xml".

And in fact you can't even do the latter because it's ambiguous in proxy
resolution whether content type is supposed to represent the content type
that should be returned by the proxy resolution server or the ultimate
content type you are looking for at the target SEP.

This has been driving me nuts in the spec!

Breaking them apart FINALLY solves this problem and allows an XRI author to
explicitly state the media type they want returned from a proxy resolution
service separately from the media type of the SEP they want selected. 

This is another argument for making the value of _xrd_r a media type just
like _xrd_a and _xrd_m.

=Drummond 




-----Original Message-----
From: Victor Grey [mailto:victor@idcommons.org] 
Sent: Tuesday, February 28, 2006 9:58 AM
To: xri@lists.oasis-open.org
Subject: Re: [xri] Proxy resolver nightmares

Tan, William wrote:
<snip>
> I tend to agree with you on sticking to only clients and resolution
> servers in XRI resolution doc,

I was at a conference where there was a representative from Liberty, 
who ruefully admitted that while SAML 2.0 "really wasn't that 
difficult" there was little chance of adoption by independent 
developers, because the specs were so impenetrable.

I don't want to see us go down that road.

Gabe expressed some concern lately that WD10 had lost some of the 
clarity around describing the actual resolution process, and I've been 
worrying about the same thing. I just woke up to the fact that the 
reason for this is the munging together of resolution and proxy web 
service.

Besides clarity, there are other good reasons not to mix these two 
subjects together. XRI resolution needs to be nailed down so that the 
early adopters can start building XRI authority servers and clients. 
Once there are a few of these around, and we are able to test our 
clients against each other's servers, we will have a much better idea 
of what the actual requirements for a proxy resolver are.

We are, imho, over-determining the proxy resolver design right now, as 
well as spending way too much time on it. Once we have a few good 
resolver client libraries available (I plan to release one as a Ruby on 
Rails plugin), we make it possible for web service developers to start 
creating a whole ecosystem of proxy resolvers, and this is desirable, 
yes?

But we don't know what their needs are yet. We do know that they will 
need a proxy service API spec that they can read and comprehend, based 
on the premise that they have a client available that can resolve an 
XRI and return a complete XRDS. The web service developer's job then, 
will be to parse the XRDS and implement the proxy API, a type of 
process web service developers are familiar with (for instance with 
RSS). Let's let that API be evolvable and informed by some real world 
experience.

> but I'm afraid you're right that it's a
> little late (Les & I had already given up resisting.)
Better late than never. Start resisting again  ;-)


> BTW, Will you be joining the special TC call this afternoon 4pm PT?
I will try.

=vg


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php