xdi message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Minutes: XDI TC Telecon Friday 2012-07-20
- From: Drummond Reed <drummond.reed@xdi.org>
- To: OASIS - XDI TC <xdi@lists.oasis-open.org>
- Date: Sun, 22 Jul 2012 23:03:18 -0700
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 20 July 2012 USA
Time: 9:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
ATTENDING
Giovanni Bartolomeo
Bill Barnhill
Markus Sabadello
Les Chasen
Drummond Reed
Joseph Boyle
REGRETS
Mike Schwartz
Phil Windley
THE ETHERPAD LINK FOR TODAY IS:
***** NEWS & UPDATES *****
--- OPENXDI (OX) TEST TOOLS
Bill said that he has been looking at the OX server and OX test tools. His plan is to map the error messages to HTTP status codes. He hopes to have the map ready for the next call.
--- CLOUD IDENTITY SUMMIT
Drummond reported that it was a very busy and content-rich conference. There were no explicit XDI sessions -- the only XDI-related announcement was the Respect Network announcement that Neustar and Swisscom were Founding Partners. However there was lots of coverage of OpenID Connect - and also Craig Burton's controversial pronouncement that "SAML is dead".
***** DECISION POINT QUEUE REVIEW *****
See the top of the wiki home page:
--- LITERAL CONTEXTS
Drummond reported that he had a long talk with Mike at the Cloud Identity Summit about the "literal contexts" proposal -- the proposed restriction in the graph model of allowing relational arcs to point to literal nodes (vs. pointing to attribute singleton nodes). This issue is so vital that Mike and Drummond agreed it should go to the top of the queue for the next call.
Bill said that he understands the impact that such a change might make and that the TC should consider it carefully.
Drummond said he would post a separate formal proposal explaining the need for using literal contexts.
--- SERIALIZATION
There is still consensus that we want to complete the additional serialization proposals as soon as possible. We reordered the priority of the remaining proposals to:
1) The JSON Serialization Rules proposal:
2) The Literal Datatype Rules proposal:
We agreed to deprioritize the following two proposals as they are non-normative:
1) The XDI Display Format rules proposal:
2) The non-normative Serialization Statement Order proposal:
# DRUMMOND to send a separate message to the TC list requesting that any alternative proposals should be posted by next Wednesday.
***** DECISION POINTS FOR THIS CALL *****
The top of the decision queue is currently serialization-related proposals.
The top priority for this call is the contexts= parameter for MIME types as proposed in:
Per his action item from last week, Markus posted a set of use cases for the contexts parameter at:
Markus ran through an explanation of his writeup on that page, explaining the advantages of a client being able to request explicit contexts when it needs it and not receive it when it doesn't.
Joseph wondered if the contexts=1 would actually save clients from needing to parse XRIs. There was agreement that that they would not need to be parsed.
Bill suggested we should treat the two options as as two different serialization formats, not options on one format. He believes we should have only one format, whether it is contexts=0 or contexts=1. His biggest concern is that with any time we have a choice of multiple options, we should try to avoid them because it increases complexity.
He put it this way: "What I want is to be able to, when asked the question 'What is the XDI format?' to be able to say that *this* is the XDI format and end the answer, not to have to say something like 'This is the format, iff you have a MIME type parameter of contexts and it's value is 1, and this is the format if the MIME type parameter contexts is absent or 0.'" The more options, the higher complexity, the less adoption, the lower the chance of XDI success.
This is not to say that implementers should be prevented from doing an XDI operation parameter to specify the response is in the equivalent of the contexts=1 format. It simply means that a minimally compliant XDI producer or consumer only needs to handle the one format, the equivalent of contexts=0.
Drummond agreed with Bill's point about eliminating options wherever possible, and that ideally there would be one single serialization format with no parameters for everything. However in this case, Drummond believes both contexts=0 and contexts=1 are needed. He summarized it this way:
-
The contexts=0 option must be supported since it is the default for sending messages and thus is an obvious default for receiving them as well.
-
The contexts=1 option is the only option that reproduces 100% of the statements in a graph in a JSON format, and thus is extremely useful to very simply clients who do not want to include any XRI parsing features to analyze a response graph.
- There is very little work involved with an XDI endpoint producing both formats, and a high degree of benefit to clients to be able to choose the format they want.
So Drummond's recommendation is that XDI endpoints MUST support both contexts=0 or contexts=1, but contexts=0 should be the default (including if is no contexts= parameter present in the request).
Joseph recommends contexts=0 format be normative, and that contexts=1 should be optional. He is also okay with having only contexts=0, i.e., no parameter
Markus recommends that both formats are required, and that the default should be contexts=0.
We agreed to think about it and revisit the proposal next week.
***** 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]