[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of special XRI TC telecon on Proxy Resolution Interface
Following are minutes on yesterday's special call held about the proxy
resolution interface - the last major issue before we can publish Working
Draft 10.
Date: Tuesday, 28 February 2006 USA (Wed morning Australia)
Time: 4:00PM - 5:00PM PT
PRESENT
Gabe
Drummond
Les
Wil
Steve
The relevant email threads that preceeded the discussion are appended below.
Early in the call we established consensus that the proxy resolution
interface (the "HTTP interface") should support the two "endpoints" of the
spectrum, i.e., that a proxy resolver should provide either the full XRDS
document resulting from proxy resolution or just a single URI as a 3xx
redirect.
Since the former is a "programmatic" output, we then discussed providing the
latter as a programmatic output by specifying it using the media type
"text/uri-list". There was consensus that this was a good approach for three
reasons:
1) It establishes that one way of specifying the proxy resolution interface
is via by media types supported, similar to any other web server.
2) This allows other media types to be developed that represent other
outputs of a proxy resolver (such as an RDDL document).
3) It also allows XRI authorities to advertise the capabilities of their
proxy resolvers via the MediaType element of their community root XRDS.
The balance of the discussion focused on whether there was any "midpoint"
between the two extremes of the full unfiltered XRDS on the one hand and a
URI list/3xx redirect on the other hand.
After examining the various tradeoffs, it was agreed that the best
compromise was to provide an output that let client applications take
advantage of a proxy resolver's ability to do service endpoint (SEP)
selection and URI construction but that did not arbitrarily pick any
particular element or set of elements for the output.
Thus the consensus was that the best "midpoint" option was to return just
the final XRD, represented by requesting the media type
"application/xrd+xml". Secondly, when SEP selection is requested, this XRD
would be "filtered" to include only the matching SEPs. In addition Wil made
the suggestion that the URI elements in these SEPs could be "fully expanded"
by the proxy resolver, i.e., the append attribute would be processed by the
proxy resolver to build the fully constructed URI and then the proxy
resolver would reset the append attribute to "none" so that the client
application can consume the URI attribute directly.
This results in a clean matrix of five options for proxy resolver output:
XRDS XRD URI
AUTH RES ONLY Full XRDS Final XRD N/A
SEP SELECTION Full XRDS* Final XRD* URI list**
* In both these cases, the final XRD is: a) filtered to include only
matching SEPs, and b) in those SEPs, all the URIs would be fully expanded.
** This is returned in text/uri-list form if that is requested, otherwise as
a 3xx redirect.
Another byproduct of the discussion was to establish consensus around the
use of the following terms in Working Draft 10. Drummond will send these in
a separate email so XRI list members can comment.
The final issue discussed was the use of the_xrd_r (Return) input parameter.
Drummond explained that having this as an explicit parameter solved the
problem that without this, the _xrd_m (MediaType) parameter was "overloaded"
to represent both the content type requested from the proxy resolver AND the
MediaType of the requested SEP. This created problems in the ED 06 spec.
However since MediaType can also be sent to a proxy resolver via the HTTP
Accept header, we now just need to decide which parameter (_xrd_m or _xrd_r)
is represented by this Accept header when it is included.
Gabe made a suggestion that Drummond believed would solve the problem.
Drummond will send a separate writeup to the list so everyone can look it
over, then put it in ED 07.
The last topic discussed was the Working Draft 10 schedule. Given that the
final technical issues are settled (we believe), Drummond will try to move
heaven and earth to post Editor's Draft 07 by end-of-day Wednesday. The
standard XRI TC call on Thursday 4PM PT (Friday morning Australia) will be
dedicated to reviewing ED 07. Then Working Draft 10 will be published as
soon after that as feasible.
=Drummond
-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Tuesday, February 28, 2006 3:36 PM
To: XRI List
Subject: [xri] Ending proxy resolver nightmares
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
---------------------------------------------------------------------
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]