RE: [xri] Revised XRI resolution output proposal

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

Sorry, I may not have been clear in my previous email about CanonicalID.

The key conclusion of the previous email was that "all the necessary
metadata to describe a service endpoint MUST be in the Service element."
That way the only job of an XRI resolver -- either local or proxy -- doing
the service endpoint selection phase is simply to select the service
endpoint and then return it to the calling application.

By this logic, if CanonicalID is one of the required elements of service
endpoint metadata, then by definition it must be in the Service element.

So, from a spec standpoint, the only revision would be to add CanonicalID as
an optional child element of Service. So now both ProviderID and CanonicalID
would be optional child elements of both XRD and Service. Which makes sense,
because they can be used in both contexts.

In my discussion with Andy Dale of ooTao yesterday, our conclusion was that
many XRI authorities may impose the requirement that the CanonicalID in a
Service element must match the CanonicalID for the XRD itself. That's a
reasonable policy. However other XRI authorities may have different policies
that allow a different CanonicalID in the Service element. And that's fine
too.

All we're responsible for in XRI resolution is defining a clean, stable way
for an XRI to be resolved into a set of metadata. Specifically, into one of
three things:

1) An XRDS document (that fully describes the target resource).
2) A service endpoint, expressed either as an XPath name/value array or as a
subset of an XRDS document (that's this proposal).
3) A single URI.

See also my next email about the _xrd_r parameter providing control over
this.

=Drummond 

-----Original Message-----
From: Chasen, Les [mailto:les.chasen@neustar.biz] 
Sent: Saturday, February 25, 2006 2:42 PM
To: Drummond Reed; xri@lists.oasis-open.org
Cc: Gabe Wachob
Subject: RE: [xri] Revised XRI resolution output proposal

Where did the CanonicalId in the service block come from?  From a
previous email I put out two test cases:

1. If I have the following XRDS

<XRDS>
....
<CanoncialId> foo </canonicalid>
<service>
...
</service>
</xrds>

Then the proxy server would return
<service>
<CanoncialId> foo </canonicalid>
...
</service>

IMHO this is confusing.

2. If I have the following XRDS

<XRDS>
...
<canonicalId> foo </canonicalid>
<service>
<canonicalid> bar </caonnonicalid>
...
</service>

Is test case 1 valid?  Are we taking the CaonicalId that is seen outside
the service block in a full XRDS and putting it in the service block
during proxy resolution?

Is test case 2 valid?  Are we saying that a user can put a CanonicalId
in the service block?  If so, why?  I thought you said that was not a
needed requirement in a previous email. 
 
I-Name:  =les.chasen 
 
-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net] 
Sent: Saturday, February 25, 2006 5:23 PM
To: xri@lists.oasis-open.org
Cc: Gabe Wachob
Subject: [xri] Revised XRI resolution output proposal

The discussion of the XML output format from the service endpoint
selection
phase of XRI resolution has raised a larger issue. We started with the
assumption that the output of service endpoint selection was a single
URI.
Then...

* We revised that to an array of URIs so that consuming applications
could
make their own choices of transport protocols (such as choosing an HTTPS
URI
vs. an HTTP URI).

* Then Steve raised the need for consuming applications to know the
CanonicalID(s) associated with the service endpoint, so we agreed on
Thursday's call to add a list of CanonicalIDs.

* Today, working on the issue of an XML output format for the results of
service endpoint selection, I realized that there are at least two other
items of metadata about a service endpoint that a consuming application
may
need to know:

	1) The Type (which may not have been part of the input
parameters
because a Path parameter or a MediaType parameter or even null
parameters
may have been used to select the service endpoint).
	2) The ProviderID (for applications that need to know this to do
things like download SAML metadata regarding the service provider --
this is
already a hard requirement of the SAML-based XRI authentication service
being developed at XDI.org).

* Finally, I had the realization this morning that since XRDs are
extensible
and may include other metadata describing a service endpoint, we can't
even
make an arbitrary decision about which service endpoint
elements/attributes
should be returned to an application as the output of service endpoint
selection.

Conclusion: 

1) The output of the service endpoint selection phase of XRI resolution
should be the selected <Service> element from the final XRD.

2) This Service element should contain all the metadata that the service
author wishes to make available to a consuming application (including,
for
example, the CanonicalID).

3) When accessed via a local API, this should be expressed as an array
of
name/value pairs in which the names are the fully-qualified XPath names
of
the elements and attributes in the selected Service element and the
value is
the contents of the element/attribute. Example:

xri://$xrd*($v*2.0)/ProviderID, xri://!!1000!1234.5678
xri://$xrd*($v*2.0)/CanonicalID, xri://=!A1B2.C3D4
xri://$xrd*($v*2.0)/Type, xri://+contact*($v*1.0)
xri://$xrd*($v*2.0)/Type/@select, true
xri://$xrd*($v*2.0)/URI, http://example.com/ctc/=!A1B2.C3D4/
xri://$xrd*($v*2.0)/URI/@append, qxri
xri://$xrd*($v*2.0)/URI, http://a.example.com/ctc/=!A1B2.C3D4/
xri://$xrd*($v*2.0)/URI/@append, qxri
xri://$xrd*($v*2.0)/URI, https://example.com/ctc/=!A1B2.C3D4/
xri://$xrd*($v*2.0)/URI/@append, qxri

4) When accessed via an HTTP proxy resolver, the output from the service
endpoint selection phase would be simply the selected <Service> element.
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>
	<URI append="qxri">http://example.com/ctc/=!A1B2.C3D4/</URI>
	<URI append="qxri">http://a.example.com/ctc/=!A1B2.C3D4/</URI>
	<URI append="qxri">https://example.com/ctc/=!A1B2.C3D4/</URI>
</Service>

This is the only model I can see that directly supports extensibility,
i.e.,
an XRD author can add another element of metadata to a service endpoint
description and know that it will be passed to any application that asks
any
XRI resolver (local or proxy) for this service endpoint. For example,
say an
XRD author creates the following Service element:

<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>
	<Pref xmlns="http://my.example.com/pref"; >nothot</Pref>
	<URI append="qxri">http://example.com/ctc/=!A1B2.C3D4/</URI>
	<URI append="qxri">http://a.example.com/ctc/=!A1B2.C3D4/</URI>
	<URI append="qxri">https://example.com/ctc/=!A1B2.C3D4/</URI>
</Service>

Now the output via a local API for an XRI that selected this service
endpoint would be:

xri://$xrd*($v*2.0)/ProviderID, xri://!!1000!1234.5678
xri://$xrd*($v*2.0)/CanonicalID, xri://=!A1B2.C3D4
xri://$xrd*($v*2.0)/Type, xri://+contact*($v*1.0)
xri://$xrd*($v*2.0)/Type/@select, true
http://my.example.com/Pref, nothot
xri://$xrd*($v*2.0)/URI, http://example.com/ctc/=!A1B2.C3D4/
xri://$xrd*($v*2.0)/URI/@append, qxri
xri://$xrd*($v*2.0)/URI, http://a.example.com/ctc/=!A1B2.C3D4/
xri://$xrd*($v*2.0)/URI/@append, qxri
xri://$xrd*($v*2.0)/URI, https://example.com/ctc/=!A1B2.C3D4/
xri://$xrd*($v*2.0)/URI/@append, qxri

*****

As always at this stage, please send feedback as soon as you can.
Currently
this is the last remaining technical open issue to close WD 10.

=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 


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