[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XRI TC Telecon Thursday 3/2
Following are the minutes of the XRI TC unofficial telecon on: Date: Thursday, 2 March 2006 USA (Friday morning Asia) Time: 4:00PM - 5:30PM PT Event Description: Weekly unofficial call that will continue until the end of the XRI 2.0 cycle. PRESENT Gabe Drummond Steve Wil Les AGENDA The main topic was review of XRI Resolution 2.0 Working Draft 10 Editor's Draft 07, which was posted shortly before the call, and in particular the input/output section. First Drummond review the other changes made in the first third of the document. Then discussion focused on the new way of defining the XRI resolution parameters using logical names (because we do not specify any particular local resolver API) that are mapped into specific "encodings" for XRI proxy resolution (where we do specify one standard "API" via HTTP(S)). There is consensus on the 8 logical input parameters, listed below (together with their "encoding" in a QXRI): Authority Subsegment Set (authority segment of QXRI w/o leading "xri://") Path (path component of QXRI w/o leading delim) Query (query component of QXRI w/o leading delim) Authority Media Type (_xrd_a) Service Type (_xrd_t) Service Media Type (_xrd_m) Return Media Type (_xrd_r) No-Follow-Ref Flag (_xrd_n) The balance of the call was spent discussing the output types. This is a tradeoff between the interface richness (more options to provide more fine-grained control to calling applications) and spec simplicity (minimizing review and implementation time). There was consensus on the following options, which may be specified to a proxy resolver implicitly using the Accept header content type or explicitly using the Return Media Type parameter (_xrd_r - which if used will override the Accept header content type as the Return Media Type parameter value): XRDS Document (application/xrds+xml) Trusted XRDS Document (application/xrds-saml+xml) XRD Document (application/xrd+xml) URI List (text/uri-list) Since the first three are all XML document formats in which we have defined a Status element for reporting errors, we discussed how we should return errors in the fourth format, text/uri-list. It was agreed that an error should be returned with a content type of text/plain, with the error being the error code followed by a LFCR followed by an optional error context string. The final topic was the format of the XRD document output option. After a long discussion it was agreed that if service endpoint selection was not requested (indicated by the Service Type, Service Media Type, and Path parameters all being null), then this should simply be the final XRD in the authority resolution process exactly as returned from the authority resolution service. However if service endpoint selection is requested (indicated by ANY of the Service Type, Service Media Type, and Path parameters NOT being null), then it should be a "filtered" XRD to which the following filter rules have been applied: 1) Only the selected Service elements are included (all other non-selected Service elements are discarded). 2) All elements that are subject to the global priority attribute are placed in priority order. A third rule -- that the URIs in the selected services are "constructed", is under consideration. The plus is that it saves the consuming application work; the minus is that it changes the actual values that were delivered in the original XRD. # STEVE AND WIL: Discuss and make a recommendation about this third rule. Lastly, Steve and Wil took a second action item: # STEVE AND WIL: Given this consensus about a proxy resolver interface, recommend an example language-neutral interface definition for a local resolver. =Drummond
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]