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

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.