Outcome of discussion on _xrd_r and Accept Header

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

On the special TC call on proxy resolution interface yesterday, Drummond
explained an issue with the use of the_xrd_r (Return) input parameter.
Without this parameter, 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. 

Adding the _xrd_r parameter solves this problem. However it introduces a new
(smaller) one: since MediaType can also be sent to a proxy resolver via the
HTTP Accept header, we need to decide which parameter (_xrd_m or _xrd_r) is
represented by this Accept header when it is included.

The problem with simply stating that the Accept header content type should
always represent the _xrd_m value is that in this case it would ALWAYS
result in SEP selection by the proxy resolver (because _xrd_m represents the
media type you want from the final target resource, not from the proxy
resolver response). However this is going to seem very unintuitive to XRI
developers, who are naturally going to expect that the Accept header you
send to a proxy resolver represents the type of response you want back from
the proxy resolver. 

For example, if they just wanted a proxy resolver to do authority resolution
and get back an XRDS document, they'd expect to just set the Accept header
content type to "application/xrds+xml". Even more importantly, the YADIS
(www.yadis.org) development community has already baked this into the YADIS
spec that this is the Accept header you MUST use if you want an XRDS
document back from an "identity server".

However the other horn of the dilemma is that we can't just flatly map the
Accept header content type to the _xrd_r value because that would screw up
all the dumb browsers out there trying to resolve HXRIs. Those browsers,
having no concept that they are going to talk to an XRI proxy resolver, will
specify obvious Accept header content types like "text/html". But in this
case they are really the content type of the final target resource, not of
the proxy resolver response.

Gabe had the insight that led to the proposed solution, which is the
following rule set:

1) If a resolution request sent to a proxy resolver includes a content type
in the HTTP Accept header, and this content type matches one of the explicit
proxy resolver content types published in the XRI resolution specification,
then it represents the implicit value of the _xrd_r parameter.

2) If the Accept header content type value does NOT match one of the
explicit proxy resolver content types published in the XRI resolution
specification, then it represents the explicit value of the _xrd_m
parameter.

3) If the Accept header content type is null, then this represents the
implicit value of BOTH the _xrd_r and _xrd_m parameters (i.e., both are
assumed to be null).

4) In ALL cases above, if the value either the _xrd_r or _xrd_m parameter is
supplied explicitly in the QXRI, the explicit value OVERRIDES the implicit
value.

******
What this means in the end is that for the four media types specified for
proxy resolution...

application/xrds+xml
application/xrds-saml+xml
application/xrd+xml
text/uri-list

...if an application wants to specify one of these is the value for the
_xrd_m parameter, i.e., the value it wants to use for SEP SELECTION, then it
MUST specify that parameter explicitly in the QXRI. Otherwise the proxy
resolver will interpret it as the implicit value of the _xrd_r parameter.

(Usual finishing rejoinder that if you disagree with any of this, POST NOW
or hold your peace (and your piece! ;-))

=Drummond