Minutes:Joint XRI & XDI TC Telecon 10AM PT Thursday 2007-10-04

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

Following are the minutes for a joint unofficial telecon of the XRI and XDI
TCs at:

Date:  Thursday, 04 October 2007 USA
Time:  10:00AM - 12:00PM Pacific Time

Event Description:
Weekly unofficial joint call of the XRI and XDI Technical Committees.

ATTENDING

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


AGENDA

1) REVISED REDIRECT & REF PROCESSING PROPOSAL
The primary purpose of the call was to close on the Redirect & Ref (R&R)
proposal at:

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

The fifth revision of this proposal was posted Wednesday night. Following
are the items on which we reached final closure:

A) CANONICALID VERIFICATION RULE

The proposed rule is: CanonicalID verification within any XRDS document
follows the chain of XRDs within that XRDS document.

* We clarified that this was not a shift in Ref processing semantics, only
in CanonicalID verification as it applies to Refs.

* John noted that this rule means that when authority resolution service is
delegated using a Ref (vs. any other service), the delegated authority must
know about the delegation and respond with CanonicalIDs assigned in the
delegating authority's CanonicalID namespace. John said this is just like
the analogy of DNS delegation - if a domain delegates to a subdomain and the
subdomain is not configured for it, errors will happen. In our case,
resolution may still work, but CanonicalID verification will break -- as it
should.

# ACTION ITEM FOR ED06: The spec must explain that the target of a Ref for
authority resolution service must understand that it is being delegated to,
and respond with a valid CanonicalID in the delegating authority's
CanonicalID verification chain or else CanonicalID verification will fail.


B) XRDS NESTING RULE

The proposed rules are: 

	- All Redirects and Refs result in a nested XRDS document with
either a redirect= or ref= attribute identifying the Redirect or Ref being
followed. 
	- All successful resolutions of an XRDS document by a resolver
during the course of fulfilling a resolution request MUST be recorded in the
final resulting XRDS document.

* Markus explained that he was fine with this; he had just been advocating
that Redirects could follow the HTTP(S) model where they were transparent.

* We discussed the difference between Redirect and Ref with regard to
authority, i.e., that a Redirect is always coming from the same XRI
authority, just a different network location, whereas a Ref is always coming
from a different XRI authority.

* We also agreed that this policy is good for debugging.

# ACTION ITEM FOR ED06: The spec must include the explanation above about
the differences between Redirects and Refs with regard to the responsible
authority.


C) XRD LEVEL PRECEDENCE RULE

The proposed rule is: A Redirect or Ref appearing at the XRD level is
processed automatically by the resolver before service endpoint selection is
performed (or before resolution is completed if sep=false).

* This behaviour supports the ability of multiple XRIs to resolve to the
same SEP regardless of initial authority.

# ACTION ITEM FOR ED06: The spec will say that for the "merge" use case (the
case where two previously distinct authorities have been merged into one),
the best practice is for the source XRD to include BOTH an XRD-level Ref and
an EquivID or CanonicalEquivID synonym to the target.

# ACTION ITEM FOR ED06: The new Section 12 should also point out the basic
options available to XRDS authors for how they can map the initial query
identifier to the CanonicalID or CanonicalEquivID in the final XRD.


D) PRIORITY FOR REDIRECT AND REF PROCESSING

The proposed rule is: a resolver MUST try all Redirect or Ref elements in
priority order until it succeeds or they all fail. If two or more Redirect
or Ref elements have the same priority, the resolver MUST try them in random
order to support round-robin behavior. The resolver MUST continue to try all
Redirect or Ref elements at the same priority level until it succeeds or
they all fail.

# ACTION ITEM FOR ED06: Specify this very clearly so all implementations do
it consistently.


E) REDIRECT PARAMETER

On the question of whether a redirect= resolution parameter is needed to
control redirect processing, the conclusion was that it was not necessary
due to the fact that a Redirect is not switching between authorities. The
refs= parameter, by contrast, is useful because the requestor (or a proxy
resolver) may have a policy of not permitting switches between authorities.


F) ERROR CODES

We closed on the error codes in the proposal at
http://wiki.oasis-open.org/xri/XriCd02/RefProcessing -- in particular, on
replacing the current 101 REF_NOT_FOLLOWED with 260 REF_NOT_FOLLOWED.

* There was some discussion about the potential for confusion with HTTP
error codes, however this is already covered in section 14 of the spec.

# ACTION ITEM FOR ED06: Specify new error codes.


2) ISSUE #49 - MEDIA TYPE PARAMETERS FOR URI LIST

Gabe pointed out that the issue is that for popular media types, some
HTTP(S) libraries may not properly process HTTP(S) requests for a media type
that includes parameters it does not recognize. However we agreed that the
text/uri-list media type is so rare that this is not likely to be a problem.

This issue is CLOSED.


3) SERVERSTATUS ELEMENT

* Drummond explained that as he has begun to write this up in ED06, he
realized that most implementers/users will expect the ServerStatus element
to have been generated by the server, and the Status element to have been
generated by the client. It would make sense to specify it this way.

* We then discussed that if both ServerStatus and Status are optional, older
resolvers dealing with older servers can just pass through the Status
element. Newer resolvers dealing with older servers SHOULD automatically
generate the ServerStatus element on behalf of the server. Newer servers
will generate the ServerStatus element, so resolvers will only need to
generate the Status element.

* If the resolver and server agree on the status, the two elements will be
identifical. However consuming applications can always key on the Status
element, since it is the resolver's final status that counts.

# ACTION ITEM FOR ED06: Update to reflect the above.


4) SCHEDULE FOR XRI RESOLUTION 2.0 WD11 ED06 AND COMMITTEE DRAFT VOTE

All issues at...

	http://wiki.oasis-open.org/xri/Xri2Cd02/ResWorkingDraft11

...are now closed. The work plan is:

* Drummond will produce ED06 as quickly as possible (since it represents 2+
days of editing work, the goal is COB Tuesday, 10/9). At the same time,
implementers will code and test the final Redirect & Ref Processing rules
recorded today.

* We will review ED06 and place any final edits in ED07 the following week.

* We will hold the Committee Draft vote the week of Oct. 22.