Minutes: XRI TC Telecon 4pm PT Thursday 2006/05/25

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

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

Date:  Thursday, 25 May 2006 USA (Friday morning Asia)
Time:  4:00PM - 5:30PM PT

PRESENT

Marty Schlieff
Drummond Reed
Les Chasen
Gabe Wachob
Wil Tan

MINUTES

* = discussion point
# = action item

1) XRI METADATA 2.0 WORKING DRAFT 08
We discussed this new draft posted at:

PDF:
http://www.oasis-open.org/committees/download.php/18270/xri-metadata-V2.0-wd
-08.pdf

Word:
http://www.oasis-open.org/committees/download.php/18269/xri-metadata-V2.0-wd
-08.doc 

* We reviewed the following three examples of the different options we have
under the Working Draft 08 ABNF for specifying how a datetime value can be
used as a version value.

  Option #1
      xri://@example/resource*($v*($d*1994-11-05T08:15:30-05:00Z))

  Option #2
      xri://@example/resource*($v*datetime*($d*1994-11-05T08:15:30-05:00Z))

  Option #3
      xri://@example/resource*($v*datetime*1994-11-05T08:15:30-05:00Z)

* We did not reach a conclusion, as all three options have their advantages
and disadvantages. 

  * Option #1 is compact and reuses the $d namespace but requires defining
two types of defaults for $v metadata (the other being alphanumeric, i.e.,
"($v*2.0b)".) 
  * Option #2 reuses the $d namespace and does not require a new default,
but is the longest of the three. 
  * Option #3 is the "flatest" as it does not require a nested
cross-reference, but requires respecifying the subtags that are already
specified in the $d namespace.

# ACTION: All TC MEMBERS to review this and post any feedback about
preferences.

* Marty recommended that, when XRI authors have the option of nesting
metadata in different orders (such as $t metadata inside $l metadata, or
vice versa), the Metadata spec should specify the recommended order in order
to simplify the chance of false negatives in comparison. 

2) XRI TYPE METADATA 2.0 WORKING DRAFT 01

* Marty suggested that the TC consider that, instead of having this be a
separate spec, it could be rolled back into the Metadata spec, which would
go through two phases. In the short term, it would be simply be revised more
frequently than the other XRI 2.0 specs. In the longer term, it would define
a $ dictionary service that would render the entire spec dynamic, i.e., it
could be consulted by both humans and machines for $ metadata definitions.

3) SUGGESTION ABOUT SAML XRI RESOLUTION FORMAT
* Marty explained a suggestion that the TC should consider defining a
SAML-based XRI resolution format (similar to the current XRDS document but
done as a SAML document) in order to encourage adoption by SAML products. We
discussed the tradeoffs and agreed to think about this further.

4) XRI RESOLUTION 2.0 WORKING DRAFT 11
* We discussed a number of issues for WD11 that had been posted by Wil.

* The first one, regarding whether XRIs in an XRDS document needed to be
encoded in URI normal form, is currently specified in section 3.4. Wil
suggested we add an additional reference to this in sections 8.2.2 and
8.2.4.

* We discussed Wil's proposal in
http://lists.oasis-open.org/archives/xri/200605/msg00033.html to add support
for wildcard matching. The conclusion was that we will emulate HTTP Accept
headers and add * wildcard parameter support in the QXRI input parameter.
However we will not support publishing wildcards in the value of a MediaType
element in an XRD because the server needs to be more explicit about what it
supports.

# WIL to send proposed text to add to Working Draft 11 to the list for
review.

* We answered Wil's questions in
http://lists.oasis-open.org/archives/xri/200605/msg00032.html regarding
forward slash normalization. The conclusions we reached were:

  * We will follow the rule stated in RFC 3986 section 6.3.2 that absolute
XRIs with an empty path are normalized to include a trailing slash
representing an empty path, i.e., xri://@foo and xri://@foo/ are equivalent.
  * If an XRI includes a non-empty path that ends in a trailing slash, it is
NOT normalized, i.e., xri://@foo/bar and xri://@foo/bar/ are NOT equivalent.
  * In all cases, multiple forward slashes in any position in the path,
including trailing, are significant, i.e., none of the following are
equivalent: xri://@foo/bar/, xri://@foo/bar//, xri://@foo/bar///,
xri://@foo//bar/. 

* We finally closed the thread about percent encoding of the "+" character
in XRI resolution query parameters (the last message in this thread was
http://lists.oasis-open.org/archives/xri/200605/msg00024.html). The decision
was that:

  * Since the QXRI in an HXRI must be in URI normal form, all non-URI-safe
character must already be percent-encoded.
  * In addition we MUST require percent encoding of "#", "[", and "]" as
general delimiters per requirements of RFC 3986.
  * We currently require percent encoding of "&" because it is the query
parameter delimiter.
  * Because we already require these other percent encodings, we will
require percent encoding of "+" for compatability with widely implemented
CGI libraries that will transcode this into space or %20.

5) INCORPORATION OF YADIS INTO XRI RESOLUTION
We briefly discussed beginning work on the proposal to incorporate the Yadis
specification  into XRI Resolution 2.0 Working Draft 11 (see
http://lists.oasis-open.org/archives/xri/200605/msg00022.html). This will be
discussed further via email and on the next telecon.

=Drummond