OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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

Subject: Minutes: XRI TC Telecon 8-9AM PT Thursday 2008-08-14

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

Date:  Thursday, 14 August 2008 USA
Time:  8:00AM - 9:00PM Pacific Time


Gabe Wachob 
John Bradley
Markus Sabadello
Nika Jones
Drummond Reed

Eran Hammer-Lahav 



A very active discussion regarding XRDS-Simple and the future direction of
XRDS discovery started this week on the XRDS-Simple mailing list:


The specific thread of the discussion is:


Eran Hammer-Lahav, XRDS-Simple author and originator of this thread, 
joined us for this discussion. He explained that he has been thinking about
the proposals he introduced this week on the XRDS-Simple list for some time.
He feels the question falls into two parts: the discovery protocol, and the
discovery document schema.

On the discovery side, Eran said it is easier to be backwards-compatible. We
can just add new methods, such as the Link header method he suggests. Old
ones can be deprecated but continue to be supported by libraries until they
die out.

On the schema side, it would be more of a break because his suggestion is to
define a new schema which has much in common with the current schema but
also changes several elements. Eran's view is that this would make it more
generic and more broadly understandable than it is now. (Details are in his
message with the subject line "Protocol Z" on the XRDS-Simple list.)

We proceeded to discuss of some open issues about the discovery protocol. It
was pointed out that many people disagree there is any problem using the
Accept header to request a descriptor of a resource as it is a valid
representation of the resource. It was suggested that an alternative was to
specify that this representation was actually available at a different URI
that for example included a specified query parameter.

Eran agreed that you can make a case that using the Accept header is
perfectly acceptable. The problem is the way that people reply to it, i.e.,
the current protocol it is legal to return just a header rather than the
normal representation.

Eran explained that the Yahoo front page team will only return the HTML page
due to concerns that any proxy anywhere would screw it up. They also will
not add even 40 bytes for the X-XRDS-Location header due to bandwidth
considerations. (The only header they currently add is a privacy policy link
that is essential.) So their compromise is that if you ask for HEAD, they
will include the the X-XRDS-Location header in the head response.
Alternatively, if you ask for the home page but specify a particular
browser-user-agent (missed that detail), or if you request an
application/xrds+xml Accept header, it will return the X-XRDS-Location

Eran speculates that the same will be true for Google due to their extreme
sensitivity to bandwidth (down to the pixel level). 

John pointed out that these are of course new requirements for the XRI TC;
that is not unexpected when reaching the third generation of a spec. Eran
also said that this is not unusual; Yahoo typically tries to solve these
things internally before bringing them up at the spec level. He said the
same was true of feedback for OAuth -- the protocol needed to be developed
first before feedback came from the large providers.

Eran is less concerned about the discovery protocol because he thinks the
HTTP experts will eventually either come to an agreement about it or we'll
just stick with Accept headers. And the X-XRDS Header can be deprecated in
favor of the Link header, but libraries can continue to support it.

We turned our attention to the schema. On that front Eran has more issues
due to the current semantics. In short, they are heavy on describing
services related to a resource but light on describing the resource itself.
Drummond and others agreed that the latter category currently includes only
synonym elements, and acknowledged the need of OAuth and others for resource
self-description elements.

Gabe likes the idea of the next XRDS spec being vetted by a larger
community. Eran thinks that the XRDS base could be something that is modular
and separate on its own. He pointed out that the level of flexibility of
XRDS and XRDS libraries is currently so large that it is hard to interpret.
OpenID is an exception because its "profile" of how to use XRDS is so
specific. When it came to OAuth, Eran's experience was that XRDS was too

Thus Eran recommends the development of a new core v3 XRDS schema that
retains many of the current features but which makes the core schema the
base "level 1" and makes any additional "advanced" elements like Ref and
Redirect "level 2". Also, all elements would have common interpretation by
all libraries, regardless whether they only implemented just level 1 or both
level 1 and level 2.

The last part of the discussion was how to proceed. Eran has time available
to work on the specification, and is willing to join the TC. He is also
interested in having the newly announced Open Web Foundation involved, as
this would enable open source developers who otherwise would not join OASIS
to contribute.


# DRUMMOND AND JOHN to contact Jamie Clark for feedback about how such an
arrangement might work, and get back to Eran.


We did not have any time left to discuss this but will continue the
discussion on the list and it will be the lead topic on next week's telecon.

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