Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-01-08

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

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

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

ATTENDING

George Fletcher
Peter Davis
Markus Sabadello
John Bradley
Drummond Reed
Brian Eaton 
Eran Hammer-Lahav 
Breno de Medeiros
Tatsuki Sakushima

REGRETS

Nat Sakimura
Bob Morgan

# = action item


AGENDA

1) GENERIC HTTP DISCOVERY DRAFT

Eran posted the first draft last night via email to:

	http://lists.oasis-open.org/archives/xri/200901/msg00027.html

He explained that it is intended to be very generic and probably will
ultimately be referenced by the XRD 1.0 spec. He is looking for feedback on
this draft as early as possible as he plans to put another draft out as
early as tomorrow.

# ALL TC MEMBERS - Please send Eran comments directly ASAP.


2) XRD 1.0 - DNS VS. HTTP AUTHORITY ISSUE

We discussed the issue raised by Eran on Wednesday:

	http://lists.oasis-open.org/archives/xri/200901/msg00021.html

Per the discussion on the list, there are two core issues.

	a) Separation of DNS and HTTP authority and proper reflection in the
workflow of which should be authoritative for what URIs.
	b) Whether what we are creating should be a "framework" that can be
bound to different protocols (e.g., HTTP and DNS), or whether what we are
creating should be a "pattern" that, once established for HTTP, can also be
emulated in other protocols like DNS.

Another way to frame the issue is to ask, "Are we defining a discovery
protocol for all URIs or just http: URIs? Or just URIs with have an
authority component?"

Peter spoke in favor of the framework approach, saying that it would make it
easier for XRD 1.0 to be adopted by protocols such as XMPP that do not use
http: URIs and may not involve any HTTP stack. It would also help XRD
discovery be scheme-independent, rather than making it dependent on each URI
scheme.

Brian asked - what are the use cases for making HTTP authoritative for
non-http: URIs? The most commonly cited example is using mailto: URIs as
OpenID identifiers. There are a number of ways being discussed for how this
could work. One of them is to only use the domain portion of the address,
however this means discovery could proceed via either DNS or HTTP.

Peter also pointed out that using DDDS, DNS has the capability of performing
the transform on any input URI, so it could answer requests for both http:
and mailto: URIs, for example.

We returned to issue (a) - the issue of authority of DNS vs HTTP. Eran
explained that there is no dispute that http: URIs can go immediately to
HTTP for discovery. The question is whether non-HTTP URIs should use DNS
first. He explained that of the three discovery mechanisms in his proposed
draft (Link-Element, Link-Header, and /site-meta), only Link-Header is
specific to HTTP. Link-Element and /site-meta can be used via all protocols.

Eran expects that the most common deployment of XRD discovery will be a
/site-meta file in a well-known location (WKL). There was a consensus that
although WKLs are generally to be avoided, for this particular problem it is
probably the best practical solution, particularly if there is a strong
argument it can be "the last WKL needed" since everything else can register
there.

However if we are to follow the general precedent that "any place higher in
the Internet hierarchy can speak for anything lower in the hierarchy", then
DNS should be checked first for any form of URI other than an http: URI --
only with the latter can it be assumed that HTTP is authoritative.

John suggested that perhaps http: URIs should /site-meta via HTTP first,
then DNS if that fails, while other URIs should try DNS first and NOT try
HTTP if DNS fails.

Eran's objection was that for an http: URI, this would require two calls to
determine that a site does not support discovery, vs. only one under his
proposal.

So the final proposal discussed was:

	a) http: URIs wills use the 3 discovery methods proposed in Eran's
draft. If these fail, discovery SHOULD fail.
	b) For non-http: URIs, discovery MUST start with DNS, and if it
fails, discovery MUST fail (at least according to the published protocol -
if an application choses to still try HTTP, we can't stop it).

There was general consensus that failure in the latter case was an authority
issue, not a security issue, although John brought up some cases in which it
might become a security issue.

We briefly discussed the relationship between Eran's HTTP-based discovery
proposal and Peter's DNS-based discovery proposal. They agreed the two are
orthogonal, i.e., they are two different discovery protocols that both start
from a URI and end out with a metadata document. Figuring out the ultimate
relationship of the two can be deferred for the time being.

Next steps:

# ERAN will process feedback on the proposal by tomorrow morning hopes to
get out a second draft quickly.
# PETER will continue to update the DNS discovery protocol draft and will
publish the DNS trust profile.


3) XRD 1.0 - SEPARATION OF SIGNING MECHANISMS AND TRUST PROFILES

We ran out of time to discuss Brian's proposal at:

	http://lists.oasis-open.org/archives/xri/200901/msg00003.html 

However there appears to be consensus that we can separate signing
mechanisms and trust profiles as long as we can show it works. The next
steps are:

# NAT to draft a trust profile for OpenID CX.
# PETER to draft a trust profile for DNS discovery.
# BRIAN to propose first draft text for this portion of the spec (that
explains this separation, specifies the signing mechanisms, and specifies
the requirements that each trust profile must meet - assuming trust profiles
go in separate sections or even separate specs).


4) EDITOR'S TELECON WITH TC ADMINISTRATOR MARY MCRAE

We agreed to hold a special telecon next Monday 1/12 from 2-2:30PM PT
between Mary and all XRI and XDI TC editors who want to get her guidance and
advice RE drafting OASIS-compliant specs most efficiently.

# DRUMMOND to schedule this with Mary.
# ALL EDITORS to send in any specific questions to Drummond or the list by
FRIDAY 1/10.
# DRUMMOND to compile the questions on
http://wiki.oasis-open.org/xri/InfoForEditors by the end of Friday and send
a link to Mary. 


5) SPECIAL TOPIC TELECON - CLOSURE ON XRI 3.0 SYNTAX PROPOSALS

An early draft of the XDI RDF Graph Model spec was posted to the XDI TC
wiki. Drummond has reviewed this extensively with Nick Nicholas so we should
be in a position to complete an analysis of the requirements it presents
that motivate the GCS Delimiter and Xref Delimiter proposals.

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

# DRUMMOND to schedule a special telecon for 2-3PM PT (22:00-23:00 UTC) next
TUESDAY JANUARY 13.


6) CALL SCHEDULE AND NEXT CALL

We agreed to continue the current Tuesday/Thursday calls so we have
scheduled times at which to work through key issues -- this is important to
finish this spec cycle as soon as possible. We will try to minimize call
overhead and devote maximimum time to issues resolution. All editors and TC
members working issues are urged to submit them to Drummond/Peter by noon on
Mondays and Wednesdays for inclusion on the agenda of the next call.

Next call Thursday 2-3PM PT (22:00-23:00 UTC).