[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes:Joint XRI & XDI TC Telecon 10AM PT Thursday 2007-09-13
Following are the minutes of the joint unofficial telecon of the XRI and XDI TCs at: Date: Thursday, 13 September 2007 USA Time: 10:00AM - 12:00PM Pacific Time Event Description: Weekly unofficial joint call of the XRI and XDI Technical Committees. ATTENDING Gabe Wachob Les Chasen Wil Tan Drummond Reed AGENDA 1) REVIEW OF SYNONYM SECTIONS OF XRI RESOLUTION 2.0 WD11 ED04 Regarding the new synonym sections in ED04, there is consensus to remove the non-normative text currently in section 5.1 (and move it to an informative document). The other two synonym issues are a question about synonym selection rules (ED04 section 5.3) and a question about whether a dedicated synonym element besides EquivID is needed as the backpointer for CanonicalEquivID verification. On the first issue, there was consensus that the specification should be neutral with regard to the policies of what identifier a consuming application should select, so we will remove section 5.3 and just make sure the semantics of each synonym element is clear. On the second issue, the editors could not find a use case that would justify the need to use a synonym element other that EquivID as the backpointer for verification of CanonicalEquivID, so no change will be made. 2) DEFAULTING TO CID=TRUE We discussed the suggestion made by Victor Grey and Kermit Snelson at... http://lists.oasis-open.org/archives/xri/200709/msg00010.html ... that we make CanonicalID verification the default resolution mode, i.e., resolver set cid=true unless it is explicitly set to false. Wil pointed out that if we do this, current implementations that don't need CanonicalID verification and are expecting 100 SUCCESS messages will stop receiving them, because they will start receiving either a 110 CID_VERIFIED status, a 111 CID_VERIFICATION_FAILED status, or a 112 CID_NOT_PRESENT status. This led to a discussion of the impacts of upgrading to Committee Draft 02. We suspect that a number of implementations will need to change, and therefore that this is *probably* a good time to adopt this policy. However we should do some research on what OpenID libraries might be affected. # DRUMMOND to do this research and report back. 3) FAILOVER BEHAVIOUR We discussed what the spec should say about failover across multiple authority resolution service endpoints. Les pointed out that it is much more efficient for authorities to maintain multiple IP addresses in the DNS layer than to maintain multiple authority resolution service endpoints, however both solutions will work. The latter would require that either resolvers be pre-configured with multiple authority resolution service endpoints, or that resolvers periodically obtain a self-describing XRD with such info. There was consensus that we add a Failover section to the Generic Authority Resolution section. This section should say that if a community wants failover: a) Authorities in the community SHOULD publish and resolvers in the community SHOULD try multiple IP addresses for the DNS name for the HTTP(S) URI for any authority resolution service endpoint (this is already a TCP/IP networking best practice), and/or b) Authorities SHOULD publish multiple authority resolution endpoints in a self-describing XRDS and resolvers SHOULD try them in the priority order listed. 4) SCHEDULE FOR ED05 AND ED06 Drummond has updated the open issue/action item list at: http://wiki.oasis-open.org/xri/Xri2Cd02/ResWorkingDraft11 The schedule is: * Drummond will incorporate feedback and attempt to produce a release-candidate ED05 before Monday. * All comments need to be received by next week's Thursday telecon. * We will incorporate any final comments into the final Working Draft 11 upon which we will hold the vote starting Monday Sept. 24.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]