Minutes: XDI TC Telecon Friday 2014-11-14

XDI TC Minutes

Following are the minutes of the unofficial telecon of the XDI TC at:

Date:  Friday, 14 November 2014 USATime:  09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
ATTENDING
Les ChasenPeter DavisDrummond ReedAmanda NavarroHubert Le Van GongMarkus SabadelloJoseph BoylePhil Windley
GUESTSREGRETSNEWS & UPDATESPRESENTATIONS/DISCUSSIONSReport from XDI editors subcommitteehttps://wiki.oasis-open.org/xdi/XdiOneSpecshttps://github.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook

Peter said that we discussed Jira issue XDI-29 (versioning) and XDI-14 (subgraph). On the former, there was agreement that we need an overall version number for the XDI graph model, which would include the serialization format. On the latter, Joseph and Drummond and any other volunteer will work offline to figure out a better term than “subgraph” to refer to graphs that do not include root nodes.

ABNF progress?

ABNF progress?

Markus is working on implementing the removal of value context nodes:

http://xdi2.projectdanube.org/no-value-node

https://github.com/projectdanube/xdi2/tree/no-value-node

Glossary progress?

Markus has added terms for XDI Binding (without definitions) and XDI Messaging (with definitions):

https://wiki.oasis-open.org/xdi/Glossary
Correlating request messages and response message
Markus gave a demo of how request messages and response messages could be correlated, using the <#async> message parameter.

XDI Policy and Connections

Let’s continue to discuss XDI connection requests, connection invitations, link contracts, templates, community contracts, requester contracts, etc.

We created the following example flow involving a connection request:

connection request (Alice's application remembers this in her graph, or otherwise):

=alice[$msg]!:uuid:1234$do/{$do}/+ta#registration{$do}

=alice[$msg]!:uuid:1234/$is()/(=bob)

=alice[$msg]!:uuid:1234/$do/(=bob/+ca)#community$do

===========

synchronous response (if the connect request is processed immediately):

(=bob/=alice)+ta#registration$do/$is#/+ta#registration{$do}

===========

"deferred" / "preliminary" asynchronous response

=bob[$msg]!:uuid:3456/$is$msg/=alice[$msg]!:uuid:1234

===========

asynchronous response after connection request has been processed (might be 2 days later):

=bob[$msg]!:uuid:3456/$is$msg/=alice[$msg]!:uuid:1234

(=bob[$msg]!:uuid:3456/{$do})(=bob/=alice)+ta#registration$do/$is#/+ta#registration{$do}

(=bob[$msg]!:uuid:3456/{$do})(=bob/=alice)+ta#registration$do/$get/=bob<#email>

(=bob[$msg]!:uuid:3456/{$do})(=bob/=alice)+ta#registration$do/$get/(=bob/=alice)+ta#registration$do

(=bob[$msg]!:uuid:3456/{$do})(=bob/=alice)+ta#registration$do$if/.......

=bob[$msg]!:uuid:3456/$do/ ... does this need a link contract? ...

===========

bob sends alice a copy of the new link contract instance using the requestor link contract

=bob[$msg]!:uuid:6789/$is()/(=alice)

(=bob[$msg]!:uuid:6789/$set)(=bob/=alice)+ta#registration$do/$is#/+ta#registration{$do}

=bob[$msg]!:uuid:6789/$do/ ... requestor link contract ...

===========

link contract instance:

(=bob/=alice)+ta#registration$do/$get/=bob<#email>

(=bob/=alice)+ta#registration$do/$get/(=bob/=alice)+ta#registration$do

(=bob/=alice)+ta#registration$do$if/.......

============

- how does alice obtain a copy of the new link contract? options:

  1. it is embedded in the asynchronous response

  2. it is sent in a separate message from bob to alice using the requestor link contract

  3. alice retrieves it from bob via $get

- 1. and 2. may be redundant; is the "requestor link contract" needed? may be overly complicated

- maybe good practice: link contracts should allow $get on themselves
Transactional integrity
We did not discuss this topic.
NEXT CALL
The next call is next week at the regular time.