Hi Gabe,
I remember very vaguely discussions about
that. What you said makes sense, and I agree that the proxy output should
include the GCS XRD in its output.
There are a few issues though:
What
should the GCS XRD be? Is it the XRD configured in the resolver (used by
the proxy)? What if the XRD for a given GCS changes? Will the proxy “resolve”
the GCS to get the XRD for it?
Doing
so breaks the consistency between direct resolution and proxy resolution.
Currently, an application that uses the resolver doesn’t care if the
resolver got the XRDS from a proxy or by direct resolution – the resulting
XRDS will have the same structure (same number of XRD’s). It’s
not a big deal and can be dealt with quite easily.
I’m not sure if it would be a
trivial change in OpenXRI yet; we’ll need to see what changes are made to
the spec.
=wil (http://xri.net/=wil)
From: Wachob, Gabe
[mailto:]
Sent: Friday, June 23, 2006 10:51
AM
To:
Subject: [xri] Returning a
complete XRDS in proxy resolution
I have been playing with the openxri 1.0.0 proxy code and
noticed that when I request a full XRDS document back, the first XRD inside
does NOT correlate to the GCS character (e.g. "@"), but rather to the
first subsegment after the GCS. In an earlier draft of our specs, we explicitly
addressed this issue and the only sensical thing to do was to include the XRD
for the GCS authority (but only when doing proxy resolution - this is one of
the main differences with lookahead/recursive resolution).
The openxri proxy seems NOT to return an XRD for the GCS
authority and this seems broken to me. I can't find in the resolution text
where this is spelled out so I understand why it was implemented this way.
However, I think an XRDS returned from proxy resolution MUST include the GCS
authority XRD so a client knows exactly which GCS authority is the root
(even if not doing trusted resolution). I'm assuming this is a fairly trivial change
to the openxri proxy code.
I strongly suggest we add this language explicilty in 7.6
(in addition to referring to the requirements of 4.2) for when a client is
using XRI proxy resolvers. In addition, I think we should add this requirement
for section 6 (trusted resolution). While a client doing trusted resolution
verification already has to know about roots it trusts (and therefore can do
correlation with the root authority and the first non-root-authority XRD), I
think explicitness and parallelism to the non-trusted mode are important.
-Gabe
__________________________________________________
Chief Systems Architect
Technical Innovation and Standards Management
Visa International
Phone: +1.650.432.3696 Fax: +1.650.554.6817
