Minutes: XRI TC Telecon Thursday 3/2

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

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