Meeting Notes from XRI TC F2F 2008-11-13/14

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

XRI TC Members and Observers:

 

I have finally posted the meeting minutes from our F2F held last week in Mountain View after Internet Identity Workshop. I edited the same page originally used for the agenda, just substituting the minutes from discussion of each agenda topic:

 

            http://wiki.oasis-open.org/xri/FaceToFaceAgenda

 

For OASIS recordkeeping, I’m also pasting a copy of the text from this wiki page below (but you’ll find it much easier to read on the wiki).

 

My next task is to set up some new wiki pages/issues lists corresponding to our new spec deliverables. I’ll include links to these when I send the agenda notice for tomorrow’s telecon. I have to go to a dinner tonight so that agenda email not come out until tomorrow morning. In any case, mark your calendars for the XRI TC call AT THE NEW TIME: 2-3PM Pacific Time tomorrow.

 

=Drummond

 

 

***************************

Following are the contents of http://wiki.oasis-open.org/xri/FaceToFaceAgenda (2008-11-19 16:45PT).

== About ==

This page contains the minutes of the XRI TC face-to-face meeting held Nov. 13-14 in Mountain View, CA (following the [http://iiw.idcommons.net/Index.php/Main_Page Internet Identity Workshop]). The conversation was intensive on many topics and did not always follow the planned agenda, however these minutes try to capture the key points and conclusions in the order of the original agenda items.

== Attendees ==

 * Drummond Reed

 * John Bradley

 * Eran Hammer-Lahav (Thursday)

 * Tatsuki Sakushima

 * Nat Sakimura

 * Markus Sabadello

 * Mike Mell

 * Nika Jones (Thursday)

 * Les Chasen (Thursday morning phone)

 * Peter Davis (Thursday and Friday phone)

== Goals of XRI 3.0 ==

Following are the proposed goals for our third generation of specifications:

 * Draft a new suite of XRI specifications based on the [http://wiki.oasis-open.org/xri/XriAsRelativeUri XRI-as-relative-URI proposal] and the XRD proposal from Eran.

 * Make these specifications as simple, short, and complete as possible.

 * Produce a white paper explaining the XRI problem space, the evolutionary steps from the W3C TAG discussions, the XRI 3.0 suite of specifications, and example usage scenarios.

 * Hold a public review as soon as possible after the materials above are complete.

 * Make any necessary revisions and take to an OASIS Standard vote.

== Deliverables and Editing Teams ==

Following are the results of a long discussion about the best way to package the XRI 3G specs and deliverables, and who volunteered to be an editor or contributor to each.

=== #1: XRD x.0 (OASIS Standard Track) ===

This will be the new discovery format/protocol spec. It would be a single spec voted on independently as an OASIS Standard.

''Note: the consensus on Thursday was to call this spec XRD 1.0, since it is a new spec. Subsequent discussion on Friday – at which Eran was not present – leaned toward using "3.0" as the version identifier to keep it consistent with XRI 3.0. So this is still an open issue.''

Editors:

 * Eran

 * Nat

Contributors:

 * John

 * Drummond

 * Nika

 * Peter

 * Nick

=== #2: XRI 3.0 (OASIS Standard Track) ===

This is a multi-part specification that would encompass what was formerly XRI Syntax and XRI Resolution. All the parts will be considered one specification for purposes of an OASIS Standard vote.

==== Part 1: Syntax ====

This document will cover XRI 3.0 syntax. Major sections will include:

 * Intro

 * ABNF

 * Forms and Transformations

 * Binding Requirements

 * Security Considerations

Editors:

 * Drummond

 * John

Contributors:

 * Nika

 * Nat

 * Mike

 * Markus

==== Part 2: Resolution ====

This will be shorter than XRI Resolution 2.0 because it will be a profile of XRD 1.0. It will define the "abstract resolution" requirements for all resolution bindings.

Editors:

 * John

 * Drummond

Contributors:

 * Nat

 * Mike

 * Markus

 * Nika

 * Peter

==== Part 3: http: and https: Binding ====

This spec will cover both the ABNF for the syntax binding and the restful API for the resolution binding.

Editors:

 * Drummond

 * John

==== Part 4: info: Binding ====

This spec will cover the ABNF for the syntax binding. It will not define a separate resolution binding but will refer to the http/https resolution binding.

Editors:

 * Drummond

 * John

=== #3: XRI White Paper (Informative) ===

This is the white paper that will accompany the XRI 3.0 suite.

Editors:

 * Nika

 * Drummond

 * Tatsuki

=== #4: XRI Implementer's Guide (Informative) ===

This is a new document designed specifically to aid developers in understanding and deploying XRI infrastructure and applications.

Editors:

 * Markus

 * Mike

== XRD x.0 (<== version # still an open issue) ==

Eran led a review of the major points of the XRD proposal that he had covered in a 3.5 hour IIW session on Tuesday. Because XRI TC members are generally more steeped in many of the issues that others who attended the IIW sessions, this meant we dove almost immediately into the remaining questions and issues about the XRD proposal. Following are the major points of the discussion.

 * XRD should be a standalone spec that will specify both the discovery "workflow" (protocol) and the XRD schema and service selection.

 * Due to the new approach, it will work equally with URIs and XRIs. XRI 3.0 resolution will be a profile of this spec.

=== Discovery Workflow/Protocol ===

 * We covered some of the more advanced points Eran made in his [http://www.hueniverse.com/hueniverse/2008/09/discovery-and-h.html HTTP and Discovery] blog post.

 * The overall solution Eran is recommending is a combination of Link headers and dynamic mapping using the [http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-00.txt draft site-meta proposal].

 * The key addition to the site-meta proposal is a simple template format for defining the transformation of the source URI to the target URI for the associated XRD file.

 * With regard to security and trusted discovery, the consensus was that the spec should include this as long it can be simple and short.

=== XRD Schema ===

 * Eran explained the new interpretation that immediate child elements of the XRD element (except '''Service''') describe the resource itself, while the '''Service''' element and its children describe ''linked'' or ''related'' resources. The rest of the TC members agreed with this analysis.

 * One result is that the '''Service/Type''' element really describes the relationship of the described resource to the linked resource, and not the type of the linked resource directly.

 * Another result is that a second round trip may be necessary to obtain the XRD for the linked resource if further discovery of that resource is necessary.

 * There was consensus that the spec identified by the URI value of the '''Service/Type''' element MUST define whether a second discovery step MUST/SHOULD/MAY be taken (e.g., OAuth), or whether the URI value of the '''Service/URI''' element can be assumed (e.g., OpenID Authentication 2.0).

 * We did a review of existing XRD elements to determine:

  * Which were appropriate for this new XRD spec.

  * Which were specific to XRI.

  * Which could be dropped altogether.

 * Only '''Status''', '''ServerStatus''', and '''Query''' fell into the "specific to XRI" bucket.

 * '''Query''' may no longer be needed even in XRI resolution.

 * '''Redirect''' can be dropped altogether because it is subsumed by the new interpretation of the '''URI''' element as well as the '''Ref''' element.

 * '''Ref''' can be generalized for all XRDs, but will be constrained to one hop.

 * '''ProviderID''' should no longer be needed as it will be replaced by either the '''CanonicalID''' or '''URI''' elements depending on context.

 * With regard to synonym elements, at the XRD level the proposal is to constrain them to '''CanonicalID''' (cardinality zero-or-one) and '''URI''' (cardinality zero-or-more). We will investigate whether '''LocalID''' or '''CanonicalEquivID''' are still needed.

 * '''Service/LocalID''' is still under discussion.

 * '''Service/Path''' should no longer be needed.

 * '''Service/MediaType''' will remain, and MediaType will be added to the XRD level.

 * Use of the '''XRDS''' wrapper element for a sequence of multiple XRDs will be defined at the end of the XRD spec so it can be used by any other spec (e.g., XRI 3.0 Resolution) that needs it.

=== Service Endpoint Selection ===

 * It will be covered in the spec, but the selection criteria will be very simple.

 * This means the XriThree/SuperSimpleSepSelection proposal may be able to be contained entirely in this spec.

 * We ran out of time to discuss the XriThree/SuperSimpleSepSelection proposal in any depth.

== XRI 3.0 Part 2: Resolution ==

This specification can now be much shorter because it will basically describe an abstract resolution protocol as a profile of the XRD spec.

 * This profile will then be used by XRI bindings, e.g., the http(s): binding.

 * DNS resolution under xri.net should be defined in the http(s): binding.

 * We did not have time to discuss simple static transformation for discovery (e.g., append question mark).

=== Cross-Reference Resolution Proposal ===

 * We discussed the original proposal at XriThree/CrossReferenceResolution.

 * Nat suggested that in addition to supporting the '''$(uri)''' form of community root identifier that requires either an http: or https: URI, we should also support a '''$function(string)''' pattern where '''$function''' is a defined resolution function and '''(string)''' is the parameter upon which that function acts to produce the community root XRD.

=== Simple Sign Proposal ===

 * We reviewed Nat's Simple Sign proposal at XriThree/SimpleSign.

 * There was a long discussion about the various options, but the configuration shown on the XriThree/SimpleSign wiki page is the consensus of the group attending Friday's meeting (Nat, Tatsuki, Mike, John, Markus, Drummond).

 * This needs review by a larger group.

 * There was consensus that this should be the method for doing signature-based trusted resolution in XRI 3.0.

 * The view of this group is that this proposal is simple enough to be included in XRD 1.0, and that XRI 3.0 Part 2: Resolution will only need to specify this (and HTTPS) as the trusted resolution options for XRI 3.0.

== XRI 3.0 Part 1: Syntax  ==

This part of the XRI 3.0 spec will be refactored to reflect the XriAsRelativeUri proposal, and to separate out bindings into other parts. Besides that, the only major proposed change is the GCS Delimiter proposal.

=== GCS Delimiter Proposal ===

There was a long discussion on Friday about what was originally titled the "Global Cross-Reference" proposal.

 * The first conclusion is that "global cross-reference" was not the best term, since this is really more about the rules for XRI composition. We retitled the issue '''GCS Delimiter''' and subsequently posted a new writeup at XriThree/GcsDelimiter. 

 * There was consensus that the key issue is that XRI 2.0 syntax has a restriction on the use of global context symbols (GCS) that prevents composite XRIs from being composed directly from a an ordered set of component XRIs.

 * This is a major problem for XDI 1.0, as explained in the XriThree/GcsDelimiter writeup.

 * It is also a problem in XRI resolution today, since the path portion of a QXRI cannot contain a GCS character without being in parens.

 * It will also be a problem for any other future use of XRI syntax that wants to treat the path "transparently".

 * The conclusion was that removing this syntactic restriction and specifying that GCS characters are treated as subsegment delimiters just like {{{*}}} and {{{!}}} solves all of these problems.

 * It also produces a cleaner, shorter ABNF with fewer rules as shown at XriThree/SyntaxAbnf.

== XRI 3.0 White Paper ==

We had a high-level discussion about the goals of this white paper:

 * To properly position XRI and XRD in the marketplace.

 * To explain the history of the W3C TAG interaction.

 * To explain the rationale of the XRI-as-relative-URI architecture.

 * To provide specific use cases and examples of XRI shared semantics.

 * To explain the role of XRD in metadata discovery.

 * To provide specific examples of how XRD is used with technologies like OpenID, OAuth, and information cards.

 * To explain the relationship of the XRI TC and XRI infrastructure providers.

The audience is:

 * OASIS members (specifically voters on the XRI 3.0 specifications)

 * Other standards bodies (specifically W3C, IETF, ITU)

 * Web architects and developers

 * Semantic Web architects and developers

 * Enterprise IDM architects

We also discussed being able to use XDI x.0 as an example of how XRIs may be used for shared semantics.