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: 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 USA
Time:  09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)

ATTENDING

Les Chasen
Peter Davis
Drummond Reed
Amanda Navarro
Hubert Le Van Gong
Markus Sabadello
Joseph Boyle
Phil Windley

GUESTS

REGRETS

NEWS & UPDATES

PRESENTATIONS/DISCUSSIONS

Report from XDI editors subcommittee

https://wiki.oasis-open.org/xdi/XdiOneSpecs

https://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.




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