Minutes: XDI TC Telecon Thursday 1-2PM PT 2008-12-04

["Drummond Reed" <drummond.reed@cordance.net>]

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

Date:  Thursday, 04 December 2008 USA
Time:  1:00PM - 2:00PM Pacific Time (21:00-22:00 UTC)

ATTENDING

John Bradley
Markus Sabadello
Mike Mell
Tatsuki Sakushima 
Drummond Reed

REGRETS

Bill Barnhill


AGENDA

1) PROGRESS OF XRI GCS DELIMITER PROPOSAL & NEW XRI XREF DELIMITER PROPOSAL

	http://wiki.oasis-open.org/xri/XriThree/GcsDelimiter 
	http://wiki.oasis-open.org/xri/XriThree/XrefDelimiter 

Drummond explained that he had long conversations with XRI TC members Les
Chasen and Nick Nicholas this week and that understanding of the XDI
requirements that these proposals meet is much better now. He expects that
at least one more dedicated call on this subject will be necessary before we
have consensus on the XRI TC to move forward.


2) REST BINDINGS

At the Higgins Project, there has been discussion that the "logical" REST
binding of XDI to HTTP(S) in which all messages are POSTs does not take
advantage of some of the caching and other scalability features of standard
HTTP REST, where GETs, PUTs, and DELETEs are used. 

	http://en.wikipedia.org/wiki/REST

Bill Barnhill sent a message to the list about REST architecture even though
he could not make the call.

	http://lists.oasis-open.org/archives/xdi/200812/msg00021.html

We focused the conversation on what the advantages of being able to use
standard HTTP(S) GET calls would be. The three main advantages discussed
were:

	a) Familiarity to existing developers
	b) Ability to make a request just by composing a URI
	c) Caching

However all three are tempered when it comes to XDI. First, a developer must
be familiar enough with XDI to start to use it; even that much familiarity
may be enough for them to understand why we are using POSTs.

Second, while a pure URI-based request will work for anonymous public data,
it will not work for private data. XDI builds identification,
authentication, and authorization into the message layer itself. This can be
mapped down to a physical HTTP GET call, but for developers to do that
mapping already makes it more complex than a simple URI call.

Thirdly, traditional HTTP caching will generally only applies to public XDI
documents. Caching of sensitive private XDI data must be handled by XDI
servers anyway.

One realization was that XDI servers could offer a "standard" HTTP proxy
interface as a layered API over a standard XDI interface that exposes the
full functions. Call it an "HXDI" interface. An HTTP GET to the HXDI
interface would in turn produce a standard XDI message to the standard XDI
interface, which would return an XDI message to the HXDI interface, which
would then return a conventional media type to the caller.

It was agreed this merits further discussion (and input on the list from
Bill and others who could not attend the call).


3) NEXT CALL

Next Thursday at the standard 1-2PM PT time.