Proposal for _xrd_r parameter and return format

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

Per my second action item from yesterday's TC call minutes, this is a
proposal to add an _xrd_r (Return) input parameter to XRI Resolution 2.0
Working Draft 10.

Background: this originated in the decision that the standard output of XRI
resolution when service endpoint selection is requested should be not just a
prioritized list of URIs, but also a prioritized list of CanonicalIDs, so
that XRD authors have the ability to tell consuming applications the
identifier(s) they should use for a resource at a specific service endpoint.

It's easy to see how such a return value can be returned via a local XRI
resolver API, and that's out of scope for the spec. But it raised the
question of how such a result could be returned via an XRI proxy resolver
which has only an HTTP interface, and which is in scope of the spec.

The proposed solution is two parts:

PART ONE: _XRD_R PARAMETER

Like _xrd_n, the _xrd_r (Return) parameter would be a Boolean flag. The
default if it is omitted or its value is null is the implied value of
"false", which means the return type is be governed by the _xrd_m
(MediaType) attribute.

If _xrd_r="true", then the resolver MUST return an XML document consisting
of only the selected service endpoint (part two).

PART TWO: SERVICE ENDPOINT DESCRIPTOR

2) To keep it as simple as possible, the proposed return format if
_xrd_r="true is an XML document that reuses the xri://$xrd*($v*2.0) XML
namespace and just contains the selected Service element. Following is a
example:

<Service xlmns="xri://$xrd*($v*2.0)" >
	<ProviderID>xri://!!1000!1234.5678</ProviderID>
	<CanonicalID>xri://=!A1B2.C3D4</CanonicalID>
	<Type select="true">xri://+contact*($v*1.0)</Type>
	<Path match="null" />
	<URI
priority="10">http://example.com/contact/=!A1B2.C3D4?id=xri://@foo</URI>
	<URI
priority="15">http://alt.example.com/contact/=!A1B2.C3D4?id=xri://@foo</URI>
	<URI>https://example.com/contact/=!A1B2.C3D4?id=xri://@foo</URI>
</Service>

To support this return format would require that we add CanonicalID as an
optional child of the XRD Service element. This means CanonicalID could
appear at both the XRD level and the Service level exactly the way
ProviderID can currently appear at both levels. This has the additional
benefit of allowing CanonicalID to be expressed on a more granular service
level rather than just at the XRD level.

The rule would be that CanonicalID would be used directly if present in the
selected Service, or it would be "inherited" from the XRD level if it was
not present for the selected Service. In other words, CanonicalID at the XRD
level is the default for every Service unless the Service overrides it by
including 1+ CanonicalID elements.

In addition, in a Service document the values of the URI element would be
"fully constructed", i.e., they will have had the "append" algorithm
executed to produce the final URI.

******

Again, the plan is to incorporate this into ED 07 to close this issue, so
please send feedback on this proposal as soon as you can.

=Drummond