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 2012-06-29


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

Date:  Friday, 29 June 2012 USA
Time:  10:00AM - 11:00AM Pacific Time (17:00-18:00 UTC)

ATTENDING

Markus Sabadello
Mike Schwartz
Bill Barnhill
Drummond Reed
Joseph Boyle
Giovanni Bartolomeo


THE ETHERPAD LINK FOR TODAY IS:
     http://piratepad.ca/NmpLeh4qa2 


***** DECISION POINT QUEUE REVIEW *****

We agreed that the next highest priority decison is how literal values are stored in JSON.

One option is currently expressed in:
https://wiki.oasis-open.org/xdi/JSON_2waysOfEncoding
JSON programmers can write a simple filter to transform data if necessary. The cost of not using a consistent data encoding format seems much higher than the cost of writing a json converter.

The second option is expressed in the first issue listed in:
https://wiki.oasis-open.org/xdi/XdiPendingIssues
This needs to be turned into a formal proposal.

This will be our main decision point for next week's telecon.

# ALL TC MEMBERS CONCERNED WITH THIS ISSUE: post formal proposals and advance discussion on the email list as far as possible before next Friday's call.


***** DECISION POINT FOR THIS CALL *****

For this call we focused on the HTTP Message Binding proposal:

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

We agreed to simplify the message examples.

We discussed the requirement for the server to return an XDI message as the result. Bill suggested that the server should be able to return EITHER the result itself or an XRI for the result. The latter option would support asnychronous messaging.

We talked more about async messaging options. Joseph asked if there should be a difference between an protocol that opens a long-lived connection, e.g., WebSockets, vs. an async protocol like SMTP.

We discussed whether the scope of the HTTP binding proposal should be restricted to a synchronous protocol. Bill pointed out that the W3C is leaning towards adopting SPDY in HTTP 2.0. Giovanni agreed that with the HTTP protocol, only a client can initiate a connection, but at that point the connection can be used in either direction between client and server, and in a long-lived connection the server can send messages to the client (see also http://en.wikipedia.org/wiki/Push_technology).

# BILL will do a propoaal on an async protocol binding.

DECISION: The proposal Markus has started (above) will be restricted to HTTP 1.1 synchronous messaging and will not cover specifics of the message format as that will be in separate proposals.

ACTION ITEMS TO COMPLETE THE PROPOSAL

We also discussed the question of multiple messages and multiple operations in a message. Bill explained this is why he recommends one operation per message. He feels that having multiple identifiers (message level, operation level) makes it too complicated. Then put transaction support into the messaging protocol. However we agreed that message structure should be a separate proposal.

We agreed that status codes is also still open. We discussed that the question of mapping XDI error semantics to HTTP error semantics should be handled in a separate proposal.

Giovanni, who spent almost a year studying HTTP as a protocol, showed a section of a presentation about XCAP (http://www.jdrosen.net/papers/xcap-tutorial.ppt) that talks about using HTTP error codes (specifically 404 and 409) to represent XCAP error conditions that are not HTTP error conditions but XCAP error conditions. Some of these XCAP error conditions are very similar to those that might occur in interactions wth the XDI graph.

So Giovanni supports mapping of some XDI errors to HTTP errors.

# DRUMMOND to write up separate issue regarding the ABNF for XDI statements (specifically, whether it should or should not support two segment XDI statements, i.e., statements where the third segment is absent and thus by definition a variable).


***** NEXT CALL *****

The next call is next week at the regular time, despite the U.S. 4th of July holiday.



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