XDI TC Notes

Following are the notes of the unofficial telecon of the XDI TC held on:

Date: Monday, 23 November 2015 USA
Time: 10:00AM - 11:30AM Pacific Time (17:00-18:30 UTC)

The TC operates under a standing rule approved 17 July 2008 under which the TC does not hold regular official meetings and conducts all business by electronic ballot only. Unofficial weekly meetings are held to enable discussion among members but no business is conducted nor actions taken.

ATTENDING

Peter Davis
Markus Sabadello
Drummond Reed
Joseph Boyle
Lionel Wolberger
Les Chasen

REGRETS

Christopher Allen
Phil Windley

Update on Publishing XDI Core 1.0 Committee Specification Draft 01

Drummond reported that he submitted the OASIS form to request publication. Chet Ensign has confirmed submission.

Joseph has checked the WD06 into Github.

Progress on XDI Messaging, Bindings, Push

Markus reported on:

Current status of these next specs
Experiences so far based on current implementation work
Some current questions

We began with a discussion about the two forms of the response messages in the Messaging spec. In Markus’ current draft, they are:

“Light” responses, that are only the triples requested.
“Full” responses, that have the full async responses.

We discussed this terminology. TC members felt that we needed more precise terminology than “light” and “full”. After some discussion, we settled on these more technically precise terms:

Result graph is the set of XDI statements that are the result of the operation requested in a message. Return of result graphs only makes sense in synchronous messaging scenarios.
Message graph is a complete XDI message containing a result graph. This is required in asynchronous scenarios but optional for synchronous scenarios.

We agreed that the messaging request parameter for requesting a full message graph (vs. just a result graph) should be <$msg>.

We also agreed that while both result graphs and message graphs are supported with any of the XDI bindings, some combinations make more sense than others. For example, in the Direct Binding, result graphs as responses make sense, since the binding provides an implicit association between request and response. In the WebSocket Binding, it is usually necessary to use message graphs as responses, in order to achieve explicit association between request and response. There will be language both in the XDI Bindings and XDI Messaging specs that point this out.

We next discussed the “deferred” messaging scenario, i.e., the async response scenario. Markus explained that the approach he recommends is for a response message graph to contain a push link contract. That push link contract is then used at a later time to deliver a “response” to the original request message. However that “response” is actually a new independent request message that has a correlation statement to connect it with the original request message. The $push operation is used for delivering such “responses”and will be defined in the XDI Push specification.

There was consensus that this is an elegant approach that reused a concept we have already developed, so Markus should proceed with fully defining it.

We also discussed the Artifact Binding. Markus feels that the use case for it has become weak enough that it can be removed at this time—we can always bring it back if needed.

Lastly, we discussed terminology around the role of the message sender vs. the sending peer graph. Markus was thinking the term “actor” might be better than “sender” to avoid confusion with “sending peer”. But after discussion we agreed the term “sender” was the most natural for a messaging spec.

NEXT REGULAR CALL