Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-07-09

[Will Norris <will@willnorris.com>]

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

Date:  Thursday, 09 July 2009 USA
Time:  2:00PM - 3:00PM Pacific Time (21:00-22:00 UTC)

ATTENDING

Will Norris
Markus Sabadello
George Fletcher
Scott Cantor
Nika Jones
Joseph Holsten
John Bradley
Nat Sakimura


AGENDA

1) CHOOSE NOTE TAKER

Will volunteered to take notes


2) XRD 1.0 - LINK PROCESSING RULES

Will summarized the two approaches being discussed in the following  
thread from the list:
     http://lists.oasis-open.org/archives/xri/200907/msg00063.html

George stated that he basically interpreted the two arguments as  
"depth-first" traversal (what Drummond referred to as "link priority  
order model") vs "breadth-first" (what has been otherwise called the  
"flat model").  Will concurred, but clarified that the link priority  
order wasn't necessarily depth first.  It could actually be either,  
depending on how the priority is specified.

John said that priorities should be applied within the context of  
links having the same rel value.  But what if the linked resources are  
related, but don't actually have the same rel value?  For example,  
what if one linked resource has a generic "openid provider"  
relationship and another has a more specific "openid 1.1 provider"  
relationship?  It was suggested that the previous statement be  
broadened to say that priorities should be applied within the context  
of "selected links", however those links happened to be selected.   
Will pointed out that the language in the spec already includes some  
provision for this, but stating that multiple selections should be  
done.  From section 3.3:

> For example, if an application is looking for all image resources,  
> giving higher preference to the JPEG formats over PNG, it will  
> perform two selection processes, one for each media-type, and assign  
> the resources in the JPEG set a higher preference value.


Will mentioned that one argument in favor of breadth-first selection  
is to think of LRDD.  Even though LRDD itself doesn't specify what  
order the three methods should be used, for XRD it's been suggested to  
start specific and work out from there.  So you would first look for a  
<link> element in the body of the content, then the HTTP Link header,  
and finally the host-meta document.  The preserves the idea that the  
most specific authority should have precedence (ie, the "owner" of the  
document over the "owner" of the domain).  John added that this is  
true unless there is reason to believe that the content of the  
resource cannot be trusted, in which case you may want to use a  
different order.  Applying the same logic, Will said that it made  
sense for linked resources in the first XRD to have precedence over  
any linked resources in linked XRDs, regardless of priority.

There was then discussion about "including" an external document vs  
pointing to an alternate descriptor that can be used for the same  
resource.  Scott questioned whether XRD linking within an XRD should  
be done in the same way as from an HTTP header.  Should the rel  
values, or even the mechanism, be the same?  While the semantics are  
the same -- the idea of finding a related resource, the actually  
meaning of the linking may be different.  For example, if XRD linked  
from another XRD MUST be fetched and included into the first document  
in order to properly understand the descriptor, then that is something  
very different and likely warrants a new XML element.  He mentioned  
XInclude as a similar example.  George agreed that including another  
XRD is significantly different to a linked resource with a  
relationship of "describedby".  Joseph added that the existing  
semantics of "describedby" as defined by POWDER would indicate that  
having a bunch of "describedby" resources should be unioned.

Scott's interpretation of Eran's email was that this should all be  
outside of the spec.  The processing rules should be left for profiles  
of XRD.  Joseph mentioned the efforts that were made in RDF and didn't  
really work.  Scott agreed, saying that we can try and do a whole lot  
of work, and still end up in the same place (profiles having to define  
processing rules).  Selecting links is something that should be part  
of the XRD processing model, but FOLLOWING them is not.  Put another  
way, selecting services is part of the core processing model, but  
USING them is not.  Scott clarified that he is not suggesting that  
processing rules for linked XRDs shouldn't necessarily be a part of  
the initial deliverable, it's just a question of structuring the  
spec.  If we need to define  specific rel value for XInclude, we can  
do that, but it should be done in a separate section, if not a  
separate document.

Will agreed, saying that he felt this was more or less the same  
problem as having multiple HTTP Link headers that point to separate  
XRD documents for the same resource.  LRDD itself does not specify how  
to handle that, instead saying that it will need to be application  
specific.  Whatever rules are devised for handling multiple XRDs in  
this case will likely help guide what applications should do when they  
discover a linked XRD from within an XRD document.

Scott summarized his opinion that we need to define enough in the core  
specification to allow some individuals to go build useful profiles of  
XRD.  He doesn't expect people to build actually useful code without  
that intermediary work.  There will certainly be enough in the core  
spec for people to build code against (XRD Signature, etc), but  
applications will certainly need additional profiles to be useful.


3) OTHER XRD 1.0 ISSUES

Will asked for a quick reading of how people felt about moving the  
Signature element to the bottom of the document.  He and Scott and  
talked about it briefly off-list, and there was question as to whether  
SAX parser might care.  Will asked if anyone familiar with SAX  
(specifically Markus and Nika) was aware of this being a problem.   
Nika didn't imagine there would be any problem, since they would have  
to parse the entire document anyway in order to build the  
canonicalized document used for the XRD Signature.  Scott clarified  
that they might want it higher in the document because if the parser  
knows ahead of time that the document isn't signed, they don't need to  
worry about c14n.  No one seemed to think this was a very big concern.


4) LRDD - SUBJECT OF A HOST-META XRD

see: http://lists.oasis-open.org/archives/xri/200907/msg00068.html


5) OTHER LINK HEADER/HOST META/LRDD STATUS/ISSUES

see: http://lists.oasis-open.org/archives/xri/200907/msg00068.html


6) XRI SYNTAX 3.0 WORKING DRAFT 02 STATUS/ISSUES

Drummond is making progress but will not have this ready until later  
in the
month due to travel/vacation time.


7) NEW BUSINESS


8) NEXT CALL

The next call is next Thursday at the regular time.


## Action Items

- Scott is going to take the example XRD from section 4.2.6 of the  
spec and generate a valid signature.  This will give Nat an example,  
which he was asking for, and hopefully give us a real sample we can  
include in the spec.  He will make sure the Signature is at the end of  
the document, as was discussed on the call

- Will is going to update the spec to move the Signature element to  
the bottom of the document.  If there is consensus from TC members  
unable to attend the call, he will also remove any language in the  
spec talking about linked XRDs.  The previous processing language will  
be put back into place, specifying that linked resources should first  
be selected by whatever criteria are appropriate, and then sort that  
list in priority order.  Any language on how to process linked XRDs  
will need to specified in another document, or added to XRD at a later  
time if it is deemed necessary.