Minutes of the XRI/XDI Joint F2F Meeting 4/18-20 San Diego

Following are the minutes of the joint face-to-face meeting of the XRI and XDI Technical Committees April 18-20 at the OASIS Symposium in San Diego.

ATTENDING IN PERSON (ALL DAYS)

Les Chasen

Wil Tan

Marty Schleiff

Laurie Rae

Bill Barnhill

Marcus Sabadello

Drummond Reed

ATTENDING VIA TELECON (WEDNESDAY)

Gabe Wachob

ATTENDING VIA TELECON (THURSDAY)

Gabe Wachob

Steve Churchill

***** WEDNESDAY, APRIL 18 *****

---INTRODUCTIONS---

We all introduced ourselves – it being the first time many had met face-to-face – and welcomed Markus Sabadello to the TC, especially considering he had flown all the way from Austria. Markus is a very active OpenXRI contributor, so it will be particularly good to have another active implementor closely involved in the specification process.

---XRI RESOLUTION 2.0 WORKING DRAFT 11---

The main topic of the first day was XRI resolution. Drummond gave an overview of the partially-completed Working Draft 11 (WD11), showing the new OASIS template (many thanks to TC Secretary Laurie Rae for doing the conversion) as the new sections that have been added for:

* Discovering XRDS Documents from HTTP(S) URIs (i.e., the Yadis section)

* CanonicalID Verification

* Service References (a new subsection of the Synonym and Reference Processing section)

---OPEN ISSUES---

Our next work item was to deal with the remaining open issues on:

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

=== Issue #40 – "nodefault" subparameter of Resolution Media Type (_xrd_r) parameter. ===

(Note: this was originally called the "exact" subparameter.)

In a short discussion (which didn't actually conclude until Thurs. evening), we concluded that this parameter was indeed needed, and would serve simply to override any default match on the specified service endpoint type. Issue closed.

=== Issue #41 – Processing Rules for HTTP Accept Headers ===

The proposal from Wil is to restrict Accept header usage to Service Media Type parameter (_xrd_m). After a long discussion, it was agreed that this would very much simplify the spec. One action item was assigned:

# WIL and LES to check XDI.org's GRS proxy resolver logs to confirm that this will not heavily interfere with at least one current implementation.

Otherwise, issue closed.

=== Issue #43 – Simplify Processing of Multiple Accept Headers ===

Wil's proposal was to not require proxy resolvers to weight accept header values per RFC 2616. After discussion we agreed that as far as the spec is concerned, we should stay compliant with RFC 2616. This is easier now that the Accept header will only be interpreted as the _xrd_m parameter.

Issue closed.

=== Remaining Open Issues (#16 and #44) ===

Both of these issues are pending on XRI Syntax 2.1, and should be relatively easy to close once it is closed.

# DRUMMOND to reflect all these closed issues in WD11.

---SERVICE ENDPOINT SELECTION LOGIC (FORMERLY ISSUE #17)---

Drummond explained that he completely rewrote the service endpoint (SEP) selection section to explain the new SEP selection logic at:

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

We reviewed the logic and the pseudocode on the wiki. Overall we were relatively happy except for the complexity of the final step of the default selection logic, which was still quite complex and hard to understand.

Markus made a suggestion to simplify the logic of selecting default SEPs by selecting those with the highest number of positive selection element (SELs). This suggestion was stunning in its simplicity and has a much better result because it means that in the case of a "tie" between two or more default SEPs, both are returned rather than the current “lockout” condition. It was agreed to make this change.

# MARKUS to update the wiki page with this new default SEP selection rule.

# DRUMMOND to incorporate this simplification into WD11.

--- DISCOVERING XRDS DOCUMENTS FROM HTTP(S) URIS ---

We reviewed the migration of the text from the Yadis document into this new section. We agreed that the basic instructions were present but that it could be restructured for easier presentation and understanding.

# DRUMMOND to proceed with editing.

***** THURSDAY, APRIL 19 *****

---XRI SYNTAX 2.1---

The main focus of Thursday was XRI Syntax, and specifically the open issues on:

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

---NORMALIZATION FOR GLOBAL XREFS---

The main topic we discussed was normalization of global-xrefs (see the definition of this ABNF rule on the 2.1 ABNF page on the wiki at http://wiki.oasis-open.org/xri/XriCd02/XriAbnf2dot1).

The key issue was whether XRIs that use global-xrefs should be normalized into XRIs that use only local-xrefs, i.e., should the following XRIs normalize to be equivalent:

#1: =example+tag

#2: =example*(+tag)

#3: =example!(+tag)

There was consensus that #3 should not be equivalent to either #1 or #2. However there was a very long discussion about whether #1 should normalize to #2 or vice versa.

The primary arguments in favor of normalization are: a) to keep the normalized syntax simple, and b) to eliminate any potential confusion over the different properties of local-xrefs and global-xrefs.

The primary argument in favor of not normalizing are: a) to keep XRI composition and parsing rules simple (so all XRIs are “WYSIWYG” – What You See Is What You Get), and b) that local-xrefs and global-xrefs are actually different “grammatical” constructs as Les put it, and thus should not be normalized because they actually have different interpretations and enable construction of identifier graphs with different properties.

A straw poll at the end of the conversation had 2 TC members in favor of normalization and 5 TC members against it, so we will proceed in that direction as we prepare the spec and see if any other issues come up. However there was strong consensus that if all six context symbols (plus typeless, which is the absence of a context symbol) had distinct “grammatical” meanings, these needed to be made clear in the spec.

# DRUMMOND to prepare a wiki page proposing grammatical definitions of all six context symbols plus typeless.

---XRI: VS XRI://---

The other key issue we discussed was moving to “xri:” vs. “xri://” as the scheme identifier. There is general consensus that xri: is the better, “cleaner” scheme identifier for XRI, especially in 2.1 syntax, however the key consideration is backwards compatability. We had a long discussion about how the upgrade pain could be minimized, especially for OpenID adoption.

The final conclusion is that we should confer directly with key members of the OpenID community (particulary library developers such as Sxip and JanRain) before making a final decision.

---THE OPENXRI PROJECT---

We closed the day with an excellent discussion of next steps for the OpenXRI Project (www.openxri.org), the community open source reference implementation of an XRI resolver and server. Several TC members are preparing to commit more resources to the project, both in development and “bounties”, and Markus, Bill, and Steve all were interested in joining Wil and Gabe in the actual development work. Bill in fact adapted the project to use the Maven build system as the meeting progressed, and announced that it was functional by the end of the day. Thanks Bill!

Though the OpenXRI Project is an independent open source effort separate from the OASIS XRI TC, there will continue to be close collaboration between the two. In particular we agreed that we wanted to complete OpenXRI implementation of the XRI 2.x suite before advancing the specs into public review.

---XDI TC CHARTER---

At dinner on Thursday night, a subgroup of us discussed the proposed update to the XDI TC charter. This update is listed on the wiki at:

http://wiki.oasis-open.org/xdi/CharterRevision02

We agreed that we need to proceed with this update as soon as possible, as our current deliverable dates are 2+ years old.

***** FRIDAY, APRIL 20 *****

---XRI DICTIONARY 2.0---

Friday’s main topic was the XRI Dictionary. Our first decision was to drop the term “$” from the spec name, as it is not needed to provide the overall context of the spec, and is easily misunderstood when taken out of context.

---XBNF SECTION---

We reviewed the overall structure of the Dictionary specification, which is relatively straightforward. Each definition has six sections:

* Purpose

* XBNF Rules

* Normalization and Comparision Rules

* Resolution Rules

* Ordering Rules

* Examples

We discussed a suggestion from Marty that we consider separating out the XBNF into a separate spec, since it takes up so much of the spec.

# DICTIONARY EDITORS (MARTY, LAURIE, AND DRUMMOND) to evaluate this suggestion.

---$DNS and $IP---

In discussion the previous day, Bill had suggested that we may not need to define these entries because we could use RFC 4501 (http://www.rfc-editor.org/rfc/rfc4501.txt), which already defines a DNS URI scheme.

This decision would be relatively easy if there was also a URI scheme for IP addresses, but we were not able to easily locate one.

# DICTIONARY EDITORS to review this option.

---CLOSING---

We closed the meeting at 1PM on Friday with a strong sense of momentum to finish the XRI 2.x suite. We will continue with our weekly telecons until it is complete. Note that there will NOT be a telecon on Thursday April 26 so spec editors can continue their work; we will resume TC calls starting May 3.

xdi message