Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-03-05

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

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

Date:  Thursday, 05 March 2009 USA
Time:  2:00PM - 3:00PM Pacific Time (22:00-23:00 UTC)

ATTENDING

Will Norris
Eran Hammer-Lahav
Drummond Reed
Markus Sabadello
Nick Nicholas
Bill Barnhill 
John Bradley
Bob Morgan
Tatsuki Sakushima
Nika Jones
George Fletcher


1) XRD 1.0 - LINK HEADERS

http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-04.txt

Drummond posted his feedback to:

	http://lists.oasis-open.org/archives/xri/200903/msg00012.html

Eran believes that after the upcoming IETF meeting, this will be ready to go
into the formal IETF approval process.


2) XRD 1.0 - HOST META

http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-01.txt
Latest: http://tools.ietf.org/html/draft-nottingham-http-link-header 

Drummond posted his feedback to the list.

Eran explained that /host-meta does not itself use the link pattern (also
called "link templates" but for a number of reasons link pattern is better
term). This pattern is defined in LRDD (below) but may then be used in a
/host-meta file as needed.


3) XRD 1.0 - HTTP DISCOVERY (LRDD)

http://www.ietf.org/internet-drafts/draft-hammer-discovery-02.txt
Latest: http://tools.ietf.org/html/draft-hammer-discovery 

Eran will be pushing another change shortly just to fix one error. 

Eran recommends http://tools.ietf.org/html/draft-hammer-discovery as the URL
to publish in the future, as it will always link to the latest draft.


4) XRD 1.0 - SCHEMA

Drummond updated the wiki page to reflect the decisions on the last telecon:

	http://wiki.oasis-open.org/xri/XrdOne/XrdSchema

Still open is the question about semantics of a Subject element at the Link
level.


5) XRD 1.0 - TRUST TEAM

Discussion of XML dSig Profile:

	http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile

In particular the thread beginning at:

	http://lists.oasis-open.org/archives/xri/200903/msg00001.html

George said that he doesn't want to include the XML dSig Profile any more
than anyone else, but the extra fetch would only be a problem in certain
situations (like mobile).

It appears the general consensus is that a single signature per XRD (for
trusted XRDs) is preferable to the extra complexity that multiple signatures
would require.

We still need Peter, Brian, Nat (and anyone else on the trust team who cares
about this) to weigh in before we can close this, but they were not able to
attend today.

John and Drummond have been discussing the overall pattern but have not made
any written progress on a Synonym Binding Profile yet.


6) XRI 3.0 - SYNTAX AND BINDINGS UPDATE

Drummond reported no progress yet, but he would review Nick's draft before
next week's call.


7) XRI 3.0 - MAILTO BINDING PROPOSAL

	http://wiki.oasis-open.org/xri/XriThree/EmailBinding

Nika explained the overall idea: encoding an XRI so it can be used as an
email address. The host portion of the email address then serves as an XRI
proxy server, much like the URI binding portion of an XRI under the
XRI-as-relative-URI architecture
(http://wiki.oasis-open.org/xri/XriAsRelativeUri).

The key technical challenge is encoding the XRI within the email address.
The other requirement from a technical specification standpoint is
specifying a relation type. 

Eran noted that there is a huge discussion at the TAG list now about rel
type comparisons. He recommends that we point to the Link Header spec for
the rules about these strings and their comparison.

John noted that SMTP could even be used as an XRD discovery mechanism via
this type of an SMTP proxy service. He's not sure of any specific use cases
for this. However he recommended that if we did do it, an SMTP XRI proxy
should offer essentially the same resolution options as an HTTP proxy.

If we proceeded with such specifications, it would parse out to:

a) An XRI mailto: binding specification for the identifiers.
b) An email resolution protocol for SMTP-based resolution.

John asked whether there would be a generic email proxy, i.e., xri.net.
There was consensus that this made sense just like it does with HTTP.


8) NEXT CALL

Standard time next Thursday 3/12, 1-2PM PT (21:00-22:00 UTC).