RE: [xri] Proposal for _xrd_r parameter and return format

["Chasen, Les" <les.chasen@neustar.biz>]

I have a few comments.

1. I am not in favor of adding this capability to the spec for http
proxy resolution servers.  I feel that the capabilities already provided
for in the spec allow implementers to build edge resolution services
that support this type of functionality.  I think implementers who need
this type of functionality should be encouraged to write to programmatic
interfaces not http proxy resolution servers. 

2. If you guys want to add this then this has to be optional behavior.
We discussed this on the call but I don't see it documented.

3. This proposal is adding CanonicalId to the service block.  Is this
only used in the service block under these circumstances?  If so is that
going to add confusion?  I think it might because sometimes I will see
the canonical id in a service block sometimes I will see it outside the
service block depending on what I ask for. 

- Les

 
I-Name:  =les.chasen 
 

-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net] 
Sent: Friday, February 24, 2006 4:33 PM
To: xri@lists.oasis-open.org
Subject: [xri] Proposal for _xrd_r parameter and return format

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 




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