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: Re: [xdi] XDI TC Notes Unofficial Telecon Friday 2015-12-07


Markus: agreed that we still need to discuss the whole question of whether conversations and queues should be included in XDI Messaging or not. Let's complete the content in the current outline you've developed and then we can tackle that question.

On Tue, Dec 8, 2015 at 3:43 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
Thanks, as far as I remember Christopher thought that link contracts should get deleted after a conversation.
We haven't explored conversations/queues in detail yet, looking forward to doing that.

Not sure yet if conversations/queues should be "first class" elements of the XDI Messaging and XDI Link Contracts spec, or if they are higher level "applications".

Markus


On 12/08/2015 08:56 PM, =Drummond Reed wrote:
Markus, one comment on these (excellent) notes—in particular on these two sentences:

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. 

It's my understanding that it's not necessarily the link contracts that are created/deleted, but the messages in the conversation that are created/deleted if that's what the terms of the link contract dictate. That COULD include the link contract, but it might not.

It may be a fine point, but one worth clarifying.

Thanks,

=Drummond  

On Mon, Dec 7, 2015 at 5:15 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

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.

ATTENDING

Markus Sabadello
Peter Davis
Drummond Reed
Kapil Vats
Christopher Allen

REGRETS

Update on Publishing XDI Core 1.0 Committee Specification Draft 01

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

https://lists.oasis-open.org/archives/xdi/201511/msg00011.html


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:

https://wiki.oasis-open.org/xdi/XdiOneSpecs
http://xdi.org/xdi-spec-docbook/xdi/xdi-messaging-1.0/xdi-messaging-1.0-wd04.xml

http://xdi.org/xdi-spec-docbook/xdi/xdi-bindings-1.0/xdi-bindings-1.0-wd04.xml


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.

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








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