Minutes: XDI TC Telecon Friday 2012-05-25

xdi message

[Note: my apologies for the delay in posting these minutes - I needed to get my XDI.org email address working with OASIS again. Also, this is an especially long set of minutes due to the extensive disussion on last week's call.]

Time: 9:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)

We discussed that the mailing list volume is increasing, so we are going to start using the TC wiki to track proposals and discussions. Bill has restructured the start of the front page into a table to reflect the active proposal pages.

Each proposal page should have a corresponding discussion page - Bill has enabled this in the wiki setup.

We discussed Bill's email proposing that we change the agenda structure to more efficiently process discussions related to progression of the specs.

First, we agreed that open source project updates should be made on the wiki. On TC telecons we only need to discuss spec or protocol issues that an open source project needs the TC to address, and these should come in through the proposal process. Drummond suggested each XDI open source project that has a representative on the TC have its own update page on the wiki. Important updates can then be posted to that page every week.

Second, Bill suggested and it was agreed that we still have an option for a guest speaker or presentation to give a briefing or case study when it is relevant, especially from new implementers.

Third, Bill's suggested that on each call we take 5-10 minutes to review the "decision point queue" to add new items and reprioritize. Drummond suggested that we organize proposals on the wiki by their order in the decision point queue. Markus suggested that each decision point question state the spec it is related to.

Fourth, Bill suggested that we have a goal of deciding about at least one decision point each week. We also agreed that the goal for each decision point discussion is to make a decision, and therefore all the supporting materials for making a decison should already be in front of the TC, either as a wiki page or a spec document.

3) DEVELOPMENT OF XDI INTROS

We agreed that we need to develop tutorials, webinars, and other supplementary materials that make XDI more accessible to developers or others just getting started in the technology.

4) OASIS XDI TEST SERVER UPDATE

Markus reported that the signed contract is finished, so we can finally get started. Drummond suggested that Markus, Mike, and Joseph as the Test Server Subcommittee meet offline to make a decision.

5) SPEC REPOSITORY UPDATE

Bill gave us a walkthrough of the project, showing the DITA format of a spec document, and how the PDF is built. Drummond suggested that Bill do one wiki page documenting the process and including instructions for how new editors sign up and get provisioned. Bill has added that page at:

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

6) XDI DICTIONARY UPDATE

Drummond reported that some of the Respect Network development work now requires XDI dictionary capabilities, so he will make a formal proposal and run it through the decision point queue.

7) DECISION POINT QUEUE REVIEW

Bill suggested that we take these in order and note a definitive resolution that is final pending no objection within two weeks, or until a concrete counter proposal is advanced and formally voted on. An objection cannot be raised without a counter proposal, which becomes the highest priority decision point to resolve at the next meeting. In other words it only takes consensus at a meeting with no objection over the following two weeks to finalize, but it takes a formal vote to change something once consensus is achieved and documented without objection. Bill believes this is necessary going forward to keep charging on a steady course.

Bill proposed the following initial Decison Point Queue:

a) Should the HTTP binding of XDI use an XDI enabled version of REST?

b) If it does, should we also have a 2nd binding that is non-REST?

c) Should we use a parameter to contain a message, or something else?

d) Should we use headers to contain message, or message metadata for $GET, or something else?

e) Are any of the REST proposals sent to the mailing list this week acceptable to all?

f) If so, which do we use going foward?

g) Will that one stand on it's own, or are changes needed?

One topic was suggested to be added to the queue:

8) DECISION: SHOULD THE HTTP BINDING OF XDI USE AN XDI-ENABLED VERSION OF REST?

This was the decision we wanted to try to prioritze for today's call.

Phil suggested that even using the term "REST" is a mistake. He suggests that we should we simply be talking about "transport of XDI messages over HTTP". Or, more accurately, we could say, "The design of the XDI specification is based on the principles of REST", since this is different than saying how we are encoding and transport XDI message in HTTP.

Joseph added that the semantics of HTTP and XDI are different, and agreed that we should focus on transporting XDI messages over HTTP. The question of whether it is actual RESTful is a different one.

Several TC members felt that best reason to support not doing a strict mapping of XDI verbs to HTTP verbs is to support doing multiple XDI operations in one XDI message. Mike in particular felt that it will be a big performance hit not to do this; he said OpenXDI Project implementaton experience shows it will be very inefficient not to be able to bundle multiple operations.

DECISION: The HTTP binding of the XDI protocol will not be restricted to "an XDI-enabled version of REST", i.e., to one XDI operation per message using the HTTP verb set. There was consensus that the HTTP binding of the XDI protocol should support sending multiple operations in a single message.

Relative to this decision, Bill asked that the spec include a way for an XDI server to indicate that it does not support sending more than one operation per message.