OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: XDI TC Notes Unofficial Telecon Friday 2015-12-07

XDI TC Notes

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

Date: Monday, 7 December 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.


Markus Sabadello
Peter Davis
Drummond Reed
Kapil Vats
Christopher Allen


Update on Publishing XDI Core 1.0 Committee Specification Draft 01

Joseph has made the necessary changes and Drummond is reviewing them.


We did not cover this topic since we agreed that we would require Joseph’s input.

XDI Messaging, Bindings, Push, Connections

Markus will give an update on the XDI Messaging, Bindings, Push, and Connections drafts.

Markus has published WD04 of XDI Messaging and WD04 of XDI Bindings. They can be found in the OASIS document repository as well as here:



Markus explained that a lot of content has been added/merged into the XDI Messaging spec, including content that was previously part of XDI Connections and XDI Push, which we decided to remove from the list. Markus said that these WDs are not ready for implementation or in-depth review, and that more work on the content is needed, but that the specs are getting “structurally” stable, i.e. the basic outline should not change much anymore. Also, a lot of example messages have been added. High-level feedback about the functionality described in the spec is possible at this point.

Markus mentioned that topics in the XDI Messaging spec such as “push contracts”, the “$push operation”, and “link contract “instantiation” are all closely related, and that DocBook’s cross-reference feature is used to express such relations. Also, several sections that are currently “parked” in XDI Messaging should really go into the XDI Policy spec.

We recalled that we considered renaming “XDI Policy” to “XDI Link Contracts and Policy”. We also recalled that so far no DocBook version of this spec has been created, but that Dan Blum had done early work using Google Docs. We agreed that developing this spec is just as important as XDI Messaging.

Markus introduced several new appendix sections called “Standard Link Contract Templates”, “Standard Message Templates”, “Common Link Contract Patterns”, and “Common Messaging Patterns”. We had a brief discussion whether all appendixes are non-normative, or if normative appendixes are possible.

We discussed the relation between XDI Messaging and XDI Discovery. Markus said that while the latter clearly depends on the former, the opposite is not true. XDI Messaging mostly works on the abstract layer of XDI peers and is not much concerned with underlying bindings and discovery.

Christopher asked whether “pre-” and “post-” states of conversations are possible in XDI messaging. This would involve link contracts that are created at the start of a conversation, and deleted at the end of a conversation. Christopher also suggested that there should be “receipts” that record in a non-repudiable manner the set of operations that happened under a link contract. Markus replied that we had never talked specifically about “receipts” in XDI, but that a response message can be considered a confirmation that a request message has been successfully executed.

We also discussed whether higher-level messaging concepts such as “conversations” and “queues” should be covered by this spec.

Markus said that especially the $send operation will need some more work, in order to accommodate the various use case we had been discussing in the last few months. For example, a (sending and/or receiving) peer may be in the context of another peer in order to model endpoint/agent relationships. This can also be used to express a “routing history” of all peers a message has passed. This may sometimes be desirable and sometimes not. In other words, the $send operation has to be very flexible in order to satisfy all possible messaging/routing use cases.


The next call will be the following week at the usual time (Monday 10AM PT). The link to where agenda items can be posted for the next meeting is: https://docs.google.com/document/d/19oDl0lbb56Grehx2a5flZnhrgnua5l8cVvC_dJ8fTXk/edit?usp=sharing

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]