MINUTES: Official XRI TC Telecon Friday 10/14 8AM Pacfic / Midnight Japan

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

MINUTES OF THE  OFFICIAL XRI TC TELECON FRIDAY 2004/10/14 8AM PACIFIC / MIDNIGHT JAPAN

 

ROLE CALL

 

Dave McAlpin

Marc Le Maitre

Chetan Sabnis

Mike Lindelsee

Gabe Wachob

Victor Grey

Marty Schlieff *

Dave Wentker

Steve Churchill *

Peter Davis

Owen Davis

Drummond Reed

Ajay Madhok

Aman Teja *

Kunal Gandhi *

Bill Barnhill

Ning Zhang

 

* Non-voting member

 

A majority of voting members of the TC were present.

 

 

1) XRI SYNTAX 2.0 COMMITTEE DRAFT 02

The final Working Draft (10b) of XRI Syntax 2.0 was posted at the following links:

 

 * PDF: http://www.oasis-open.org/committees/download.php/14896/xri-syntax-V2.0-wd-10b.pdf

 

 * Word: http://www.oasis-open.org/committees/download.php/14895/xri-syntax-V2.0-wd-10b.doc

 

All changes since Committee Draft 01 are shown in revision marks, and changes since Working Draft 10 are summarized in a previous email to the list.

 

The TC members discussed the final comments and wording changes submitted by Gabe Wachob on Wednesday and incorporated into the drafts linked above (see http://lists.oasis-open.org/archives/xri/200510/msg00016.html). There was concensus on these changes.

 

With no further changes, Peter Davis moved and Dave McAlpin seconded the following motion:

 

BE IT RESOLVED that XRI Syntax Working Draft 10b be advanced to XRI Syntax 2.0 Committee Draft 02.

 

The motion passed unanimously.

 

Ajay Madhok moved and Dave McAlpin seconded the following motion:

 

BE IT RESOLVED that XRI Syntax 2.0 Committee Draft 02 be submitted to OASIS for a second public review period as required before submission for a voting as a full OASIS Standard.

 

The motion passed unanimously.

 

Drummond Reed will post the Committee Draft 02 documents and sent the notice to Mary McRae.

 

The TC then discussed the need to update the Introduction to XRIs document. Peter, Ajay, Marty, and Drummond all volunteered to help with a new draft.

 

 

2) METADATA

Marty and Drummond reported on the progress of the $t section. The proposed $t text is nearly complete, but in working on the Special Processing Rules section, the contributors realized that there were also questions about the application of $ tags.

 

It was suggested that we try to set up an editor's call on this subject. Dave suggested sending a set of examples to the list, and then seeing if we can come up with a set of rules based on these examples.

 

 

3) RESOLUTION

A new page was added to the wiki summarizing the overarching requirements motivating many of the proposed changes (see http://wiki.oasis-open.org/xri/NewResolutionRequirements.). The TC discussed these requirements individually.

 

* RR1: Any service provider should be able to provide HTTP XRI proxy resolution (i.e. resolution of an XRI embedding in an HTTP URI, called an “HXRI”) as long as they follow a set of rules specified in the XRI resolution specification.

 

The TC agreed that this was "common sense."

 

Kunal felt there was a different way of saying it, which is that HTTP Proxy Resolution SHOULD provide backwards compatability of XRI to HTTP infrastructure such that any resource that: a) is accessible via an HTTP GET request, and b) is identifiable by an XRI, SHOULD be able to be accessed via an HXRI.

 

* RR2: Proxy resolution needs to enable an HXRI to work as a link in a web browser that results in GETting a representation of a resource that the browser understands.

 

Mike clarified that "what browser understands" meant HTTP Accept Headers (and not an XRID). Peter also suggests that this needs to be any HTTP user agent, not just a browser.

 

* RR3: Proxy resolution should be able to figure out what Local Access Service to use based only on the HXRI and browser HTTP request headers. 

 

There was also agreement this was common sense.

 

* RR4: Minimize the chance of mistaking a valid HTTP URI that is not intended to be an HXRI as an HXRI. 

 

Dave felt that this needed the further requirements that you should be able to unambiguously extract the XRI from the HXRI to support comparison of XRIs. It was agreed to add this requirement.

 

Drummond also suggested that there should be a requirement that there be a form on an HXRI that is easy for humans to type into a command line. It was agreed that this is a conflictiing requirement.

 

There was a discussion about the acceptable false positive range discussion: Gabe made the point that it ultimately comes down to, "What is the chance that an HTTP URI that appears to be an HXRI is not actually an HXRI?" In other words, it is a relative number – the number of false positive HTTP URIs compared to the total number of HXRIs.

 

There was no time left on the call, so it was agreed to schedule additional calls to finish the requirements discussion.

 

4) NEXT CALLS

It was agreed to scheduled two unofficial calls next week to continue this discussion: 8:30am Pacific on both Wed and Fri.

 

 

Respectfully submitted,

 

=Drummond Reed, Co-Chair