xdi message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Minutes: XDI TC Telecon Friday 2013-02-15
- From: Drummond Reed <drummond.reed@xdi.org>
- To: OASIS - XDI TC <xdi@lists.oasis-open.org>
- Date: Sat, 16 Feb 2013 22:14:14 -0800
XDI TC Telecon Minutes
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 15 February 2013 USA
Time: 09:00AM - 10:30AM Pacific Time (17:00-18:30 UTC)
ATTENDING
Drummond Reed
Markus Sabadello
Joseph Boyle
Phil Windley
GUESTS
Animesh Chowdhury
AGENDA
NEWS & UPDATES
TRANSITIONING CO-CHAIR ROLE
Markus Sabadello is now officially the new co-chair of the XDI TC. Congratulations, Markus!
PRESENTATIONS/DISCUSSIONS
SIMPLE HTTP/S REST API PROPOSAL
Drummond and Markus recently came up with a new approach to how to provide the a simple REST binding of the XDI protocol.
We agreed that this does align with the HTTP verbs. But it also has the limitation of URI length.
Phil made the observation that the Evented API spec also supports HTTP POST and HTTP GET for the same reasons we are looking at supporting it here: to provide a simple way to send an XDI GET message with an HTTP/S GET.
Joseph suggesting that we should separate the need to support HTTP GET from the question of alignment with the HTTP methods.
We discussed two questions:
- How would this work with SimpleHTTPTransport obsolete? Do they co-exist at the same endpoint?
- Is the xdi= query parameter needed?
On the first point, it was agreed that co-existence seems to make sense. The only question is what the endpoint does if an XDI message came in as BOTH the query sting and the HTTP/S body. Drummond suggested that, rather than defaulting to one or the other, that should be an error.
On the second point, Joseph said that using a query parameter preserves the option to add other query parameters if needed in the future. In addition, certain client-side frameworks might require the query parameter format.
However Markus looked into this and did not find any. Markus also stated the case for why to make the entire query string the URL-encoded XDI JSON serialization string:
- it aligns directly with the way SimpleHTTPTransport works, i.e., the entire body is the XDI message.
- Any future need for message parameters should be handled internally in the XDI message, not via HTTP/S query string parameters.
It was agreed that we do not need to make this a high priority since we don’t yet have a strong use case for it. Drummond noted that one way to do lightweight XDI discovery queries is using XDI HTTP discovery proxies, so that may not require doing XDI messaging via HTTP GET.
DECISION POINTS FOR THIS CALL
This week's decision queue is the following set of proposals:
ABNF UPDATES
After good discussion on the list, and on the ABNF discussion page, the two variants of the current proposal were posted on the discussion page.
What we need to close on are:
- Do we want to use variant #1 or #2 (no substantive difference, just presentation of semantics about xrefs)?
- Joseph has the action to propose the simplified IRI grammar we can use.
On the first question, Markus agreed that the shorter format looked fine.
On the second question, Joseph’s proposal is:
iri-char = iunreserved / pct-encoded / sub-delims / gen-delims
After discussion we agreed that we need to break out sub-delims in order to exclude parentheses (so they must be percent-encoded in an IRI).
# JOSEPH to update the ABNF to reflect this.
Drummond next suggested we publish the our complete ABNF, including the rules copied from IRI, and note in the spec that those rules are taken from IRI.
We then addressed a different topic raised by Markus, which is that this ABNF alone does not define the whole XDI graph model. We have other constraints that also need to be defined in the XDI Graph Model specification. There was a general consensus that many if not all of those constraints could be -- and probably should be -- reflected in the ABNF.
# MARKUS AND DRUMMOND to explore this and, if promising, make a proposal.
Out of this discussion we focused on the term “peer root”. There was a consensus that it is more accurate that the term “remote root” currently used in the approved XdiMultiplicity proposal. We agreed to change it.
# MARKUS to make the change to the XDI Graph Patterns document and to the graphic on the XdiMultiplicity page.
On the subject of XDI graph model terminology, Drummond shared the table in the RESTful web services section of the Wikipedia article on REST. He pointed out that the article’s use of “collection” and recommendations for its use match ours very nicely. He also noted that although the article uses the term “element” for a member of the collection, we are using “entity” to avoid confusion with XML terminology. (We are of course using “attribute”, but it is aligned with the concept of attribute in XML.)
EQUIVALENCE LINKS (DRUMMOND & MARKUS)
This is now in Last Call after the final terminology change requested by Markus ($noref to $deref).
XDI POLICY _expression_ (DRUMMOND & MARKUS)
It was agreed this should be at the top of the decision queue for next week’s call.
DECISION POINT QUEUE REVIEW
The decision queue stack is now shown on the following three auto-generated Category pages:
See also this list of proposals that need to be developed:
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]