Minutes: Special XRI TC Telecon 1PM PT Thursday 2007-10-01

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

Following are the minutes of the following special unofficial telecon of the
XRI TC at:

Date:  Monday, 01 October 2007 USA
Time:  1:00PM - 2:30PM Pacific Time

Event Description:
Special telecon to discuss XRI resolution redirect and reference processing
as described in the minutes below.

TO ACCESS THE AUDIO CONFERENCE:
    Dial In Number: 571-434-5750
    Conference ID: 5474

ATTENDING

Gabe Wachob
Markus Sabadello
Drummond Reed
John Bradley
Kermit Snelson
Les Chasen
Wil Tan
Victor Grey


AGENDA

1) REVISED REF PROCESSING PROPOSAL
This telecon was scheduled after last Thursday's XRI/XDI TC telecon when we
had extensive discussion of Ref processing but were not able to come to
closure. 

Subsequent discussion produced an updated proposal posted Sunday night,
2007-09-30, at:

	http://wiki.oasis-open.org/xri/XriCd02/RefProcessing

The three key changes in this new proposal were:

a) Addition of a Redirect element to take over the function of what was
previously a "service ref" (which Steve Churchill pointed out operated
differently than
an "authority ref").

b) Keeping the refs= parameter as a boolean (as it was in ED05).

c) Elimination of the proposed "find all" option -- too complex to be
introduced at this stage (and can be performed by a separate utility if
needed).

Discussion was focused first on the Redirect proposal and secondly on the
Ref proposal.


2) THE REDIRECT PROPOSAL
Following are the highlights of the discussion about the Redirect proposal.

* First, it was clarified that in essence, the Redirect element is simply a
new name for what in XRI Resolution 2.0 Working Draft 11 ED05 was called a
service ref (section 12.2). 

* The primary use case for a Redirect element is remote administration of an
XRDS, i.e., it allows an XRI to be registered in a registry while the actual
service endpoints (SEPs) associated with that XRI can be managed in another
domain.

* Kermit asked: will it take the same append and priority attributes as the
URI element. The consensus was that yes, it should.

* Kermit then summarized it this way: a Redirect element is a child of the
Service element. It accepts the same attributes as the URI element. It MUST
be an HTTP(S) URI, just like the URI element in an authority resolution SEP.
When processed, the same service endpoint selection process is performed on
the target XRDS (the one returned as a result of the Redirect). Also,
synonym equivalence is verified. If saml=true, both the source and target
redirects MUST be signed by the parent authority.

* Markus pointed out that a Redirect could be at the XRD level, and that
should be supported because an XRDS may contain metadata besides service
endpoints.

* Victor asked for some additional examples. 

* After much discussion, there was a consensus that all the XRDs being
traversed by the resolver should be shown in the final XRDS document, i.e.,
that a redirect caused by a Redirect element should not be transparent to
the final XRDS like an actual HTTP(S) redirect.

# DRUMMOND to make the following changes to the Redirect proposal at
http://wiki.oasis-open.org/xri/XriCd02/RefProcessing. 


1) Specify that the Redirect element takes the append and priority
attributes.

2) Specify that the Redirect element may appear at both the XRD and Service
levels.

3) Specify that a successful Redirect MUST result in an additional XRD
appended to the current XRDS. This XRDS MUST have a redirect attribute
showing the value of the fully-constructed Redirect URI.

4) Clarify that Redirect processing NEVER produces a new CanonicalID
verification chain, whereas Ref processing (below) ALWAYS produces a new
CanonicalID verification chain.

5) Add examples showing CanonicalID verification.


3) THE REF PROPOSAL

* We continued the discussion from last week about whether a Ref should
necessarily start a new CanonicalID verification chain. There was consensus
that it should, but Les was still uneasy that the final XRD(s) in this chain
appeared under the new XRDS instead of the parent XRDS that spawned the Ref.

* Wil said that applications should be able to obtain the CanonicalID for a
QXRI without the need for any additional service endpoint selection
parameters taken into account, which we confirmed could be done by resolving
without any service endpoint selection parameters. We agreed the CanonicalID
produced under this query may be different than that produced if the QXRI
includes service endpoint selection parameters. Consuming applications can
then take their choice of the identifier(s) they wish to store.

* We clarified that Ref may contain either an XRI or an HTTP(S) URI. If it
contains the latter, it is resolved according to section 6 (the Yadis
section). It is a very important point that even if the Ref contains an
HTTP(S) URI, it is NOT processed like a Redirect, but as the start of a new
CanonicalID verification chain. The only CanonicalID that can be verified in
this chain is either the original HTTP(S) URI itself or the original HTTP(S)
URI plus a fragment.

* Victor suggests that we specify that if any CanonicalID is not verified,
the rest of the chain does not verify. There was concensus that this should
be the case for both Redirect and Ref.

# DRUMMOND to make the following changes to the Redirect proposal at
http://wiki.oasis-open.org/xri/XriCd02/RefProcessing:

1) Specify processing for both an XRI and an HTTP(S) URI.

2) Specify that if at any point in Redirect or Ref processing, a CanonicalID
is not verified, the rest of the CanonicalID chain does not verify.

3) Add additional examples of CanonicalID verification.

# DRUMMOND to answer the message Steve posed to the list about XRDS nesting.