Minutes: XRI TC Telecon 2-3PM PT Thursday 2010-01-28

[Drummond Reed <drummond.reed@xdi.org>]

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

Date:  Thursday, 28 January 2010 USA
Time:  2:00PM - 3:00PM Pacific Time (21:00-22:00 UTC)

ATTENDING

 

Scott Cantor

John Bradley

Breno de Medeiros

Drummond Reed

Eran Hammer-Lahav


1) XRD 1.0 WD 13 URI COMPARISON ISSUE

Relative to Working Draft 13...

            http://www.oasis-open.org/committees/download.php/36031/xrd-1.0-wd13.html

 

...the one issue holding us back from a CD vote is the URI comparision issue, which is summed up nicely by this email today from Scott:

 

           http://lists.oasis-open.org/archives/xri/201001/msg00162.html

 

This was the main focus of the call.

 

First we clarified that the issue of clarifying matching rules affects both Subject matching and Link/rel matching, as well as Link/type and Property and Link/Property.

 

We began with Subject matching. Scott felts that Subject matching boils down to two options: 1) refer to RFC 3986 exclusively and stop there, or 2) specify that it is application-specific, but defaults to 3986.

 

Scott also repeated his conclusion from the list conversation: if Link/rel matching must be case-insensitive, and Subject matching can’t be, then we need two different sets of rules.

 

With regard to Link/rel matching, Eran sent to the list this morning the new proposed text from Web Linking last call draft. Scott said that there are already enough dependencies on Web Linking that we might as well live with it. There was consensus on this.

 

Returning to Subject matching (which also includes Alias matching), Scott proposed that Subject & Alias comparison be application-specific. Breno, Scott, and John discussed URI normalization for certificate comparison. The issues are complex. The use of SSL was used as an example. In that context, only the hostname is used, and it is matched case-insensitive.

 

Breno brought up the requirement from a trust profile standpoint that the identification of the resource being identified is critical. We clarified that in fact that issue is really about comparison of two XRDs: do they identify the same resource? That is definitely within scope of the XRD spec.

 

We talked about Subject and Alias elements as a means of asserting synonymity outside of the normal URI normalization rules as defined in RFC 3986. After some discussion, our conclusion was that the rules should be those defined in section 6.2.3 of RFC 3986.

 

So, our final decision with regard to what XRD 1.0 should say about comparison rules are:

 

a) Comparison of Subject and Alias values MUST based on the comparison rules defined in RFC 3986, specifically section 6.2.3, Scheme-Based Normalization.

b) Comparison of Link/rel values MUST be as defined in Web Linking.

c) Comparison of Link/type values MUST be after normalization according to the rules for media types in section 3.7 of RFC2616.

d) Comparison of Property and Link/Property values MUST follow the same rules as for Link/rel values (above).

e) In section 1, we should add text that says that comparison rules for strings or URI values defined by extensions MUST be defined by the extension.

 

# ACTION: Will & Eran to maket these updates and post WD 14.

 

 

2) XRD 1.0 CD 02 VOTE SCHEDULE

 

There was agreement that after these changes are made, we will replay the same routine as last week, i.e.:

 

a) Will & Eran will post WD 14 and a note that the CD 02 vote will be opened in a few days unless anyone raises an objection.

 

b) If no objection after 3-4 days, Drummond or Peter will commence the online ballot.

 

 

3) PROPOSAL FOR AN X.509-BASED XRI TRUST PROFILE

 

Further discussion was moved to the next call.

 

            http://lists.oasis-open.org/archives/xri/201001/msg00083.html

 

4) XRI 3.0 SYNTAX AND RESOLUTION

 

            http://www.oasis-open.org/committees/download.php/35972/xri-syntax-3.0-wd03.pdf

 

Drummond said Paul Trevithick had posted a comment asking for more examples, which he agrees are needed.

 

# ACTION: Drummond to include more examples in the next WD.

5) NEXT CALL

The next call is next week at the regular time.