Thanks Kapil,
We have approved this WD06 (working draft) as CD01 (committee
draft).
Now any further work would continue under WD07.
Since Drummond is the main editor of XDI Core, I created a pull
request that starts WD07 and fixes your typo:
https://github.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook/pull/12
Thanks for reporting, please continue to report any more
mistakes/issues you find!
Markus
On 01/26/2016 03:43 PM, Kapil Vats wrote:
Hi Markus,
I was going through XDI core sepecs (http://xdi.org/xdi-spec-docbook/xdi/xdi-core-1.0/xdi-core-v1.0-wd06.xml)
and found this typo.
Please have look at word mark with * and I replaced it with
(in).
section 1.1 point number #2
Addressability : It also imposes the constraint that the
XDI identifier of every XDI contextual arc must be unique it*(in) the scope of its parent node.
Thanks,
Kapil
On Tue, Jan 26, 2016 at 11:40 AM,
Markus Sabadello <>
wrote:
XDI
TC Notes
Following
are the notes of the unofficial telecon of the XDI
TC held on:
Date:
Monday, 25 January 2016 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
Drummond
Reed
Les
Chasen
Markus
Sabadello
Joseph
Boyle
Kapil
Vats
Phil
Windley
Update
on Publishing XDI Core 1.0 Committee Specification
Draft 01
We
invited Chet to join the call but he responded to an
email this morning that he had reviewed the revised
XML document and he was satisifed that everything
had been dealt with, so he was going to proceed to
publish.
https://lists.oasis-open.org/archives/xdi/201511/msg00011.html
Joseph
noted that in the final version he sent Chet, the
SVG images did not render properly, so he is fixing
that.
#
ACTION ITEM: Joseph will send updated SVGs to Chet.
XDI
Messaging and XDI Link Contracts
Markus
is working on updated versions of both of those. For
Messaging, it will be Working Draft 05. He is doing
the work in a branch of our Github repository.
https://github.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook/tree/markussabadello
Update
on XDI Messaging Use Case Implementation
Markus
will update the TC on XDI2 documentation of the
messaging scenarios that have been implemented:
https://github.com/projectdanube/XDINinja-swing
This
covers four flows:
Request
Connection to Profile
Invite
Connection to Profile (Manual)
Invite
Connection to Profile (Auto)
Request
Bi-Directional Chat
For each one of these flows, an architecture diagram,
sequence diagram, and walkthrough are provided, as well as
the implementation.
Markus
raised the question of whether the terms
“uni-directional” and “bi-directional” should be in
the link contract spec.
He
also suggested that one or more of these scenarios
should be added to the Messaging spec as examples.
He
also pointed out that while these examples currently
use signatures, that is a dependency on the
Cryptographic Profiles spec.
Link
Contract Expiration
Markus
has seen frequent use cases for one-time-use
contracts, for example for deferred push contracts,
invitations, etc.
One
specific use case is for link contracts that only
work once, for example, to authorize a message that
can only be received once. One example is an
connection invitation that is effectively a one-time
use contract. It will only authorize a single
message that will create the link contract.
Les
brought up a use case when the owner should be
notified that a link contract is about to expire.
Drummond said that link contract expiration and
notification policy should be part of the link
contract vocabulary.
Markus
agreed that we should be using XDI policy statements
to govern link contract expiration. This implies an
additional policy branch.
Markus
pointed out that we already have three policy
branches in link contract processing:
(=bob/=alice)$do$if
(=bob/=alice)$do$defer$if
(=bob/=alice)$do$defer$push$if
Link
contract expiration could be governed by a fourth
branch. Here is an example of what this vocabulary
could look like, using $del as the branch for link
contract expiration.
(=bob/=alice)($do$del$if/$true){$do}[$msg]<$n>/&/1
Drummond
wondered if the verb for the expiration branch
should be $expire.
Link
Contracts and Storing Copies of Messages
This
is also a use case we are seeing frequently—storing
sent/received messages (much like email). We need to
discuss link contract vocabulary for this.
Markus
suggested that there are three options for where
policy could govern this:
The
link contract being referenced by the message.
The
message policy.
Global
policy for an endpoint.
Drummond
suggested that #1 is where we should concentrate
initially, since that’s already the control point.
Markus
thinks that we have two mechanisms that can
potentially be re-used for storing copies of
messages:
Messages
that are deferred and stored in a graph due to
link contract policy decision
Push
link contracts
Basic
structure of a push link contract:
(<--publisher-->/<--subscriber-->)$do/$push/<--target-address-->
(<--publisher-->/<--subscriber-->)$do/$is()/<--subscriber-->
(<--publisher-->/<--subscriber-->)($do/$push)<$xdi><$uri>/&/"<--subscriber
endpoint-->"
(<--publisher-->/<--subscriber-->)($do/$push)<$content>/&/<--light-or-content-push-->
Example
deferred message by =drummond in =markus’ graph with
an index statement:
$get{$do}[$msg]/$has/=drummond[$msg]*!:uuid:m-1
=drummond[$msg]*!:uuid:m-1/$is()/(=markus)
=drummond[$msg]*!:uuid:m-1$do/$connect/$get{$do}
=drummond[$msg]*!:uuid:m-1$connect{$get}/$is/=markus<#email>
Markus
suggested that the indexes of messages—message
logs—should be configurable so that the logs could
be organized the way the endpoint authority wants
them.
(<--AA-->/<--RA-->)$do/$has()/[$msg]
The
behaviour could be as follows:
If
a link contract has a $do/$has()
statement
with an object node, the message is kept and
indexed under that object node.
If
a link contract has a $do/$has()
statement with an empty object node, the message
is kept but not indexed.
If
a link contract does not have a $do/$has()
statement with an object node, the message is
deleted after processing.
We
agreed this simple rule covers the cases and leaves
message log indexing easily configurable for each
endpoint.
NEXT
REGULAR CALL
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
