[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: Special XRI TC Telecon 1PM PT Thursday 2007-10-01
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]