Re: [xri] Agenda: XRI TC Telecon 2-3PM PT Thursday 2009-07-09

[Eran Hammer-Lahav <eran@hueniverse.com>]

I will not be able to attend. Here is my feedback for the meeting.

> 2) XRD 1.0 - LINK PROCESSING RULES
> 
> We need to complete the decision about the "link priority order model" vs.
> the "flat model". See this thread:
> 
>         http://lists.oasis-open.org/archives/xri/200907/msg00063.html

I feel we are overstepping the scope of XRD by making it an extension of
LRDD. If XRD gives additional processing instructions with regard to
describedby links, it creates confusion and muddles the clear semantic
meaning we have.

LRDD does not recognize describedby links present in an XRD file as a valid
location for linking to a resource description (in terms of where LRDD looks
for links). While the semantics of such a link in XRD are clear and valid,
the more I think about it, the less appropriate it feels from a protocol
perspective. I just don't like the idea of treating some rel types
differently than others.

The problem with Drummond's proposal is that I am not sure how a parser can
actually apply it when dealing with imperfect matches. If an XRD has 10
links and a parser is looking for a link with more than just a single rel
type match, what should it do if it finds some matches but none is perfect
and at the same time there is a higher priority link to another XRD?

I would argue that a parser should first go through the entire XRD looking
for a match (of the desired quality), ignoring any other relation types,
including describedby. If a suitable match wasn't found, *then* the parser
looks for describedby links to other XRDs and process those in priority
order. I don't think it is appropriate to cross priorities across different
relation types.

BUT, I still don't like this entire approach of using a specific rel and
media type to mean something with such significant impact on the parsing
rules, especially with potential conflicts with LRDD and other links. It is
just asking for problems.

Linking to another XRD can have two meaning: addition or replacement.
Addition is enough because it can simulate replacement by having nothing but
a single link in the XRD. That is good enough.

What I suggest we do is define a new relation type that means 'XRD include'
and then we can remove any ambiguity about the semantic meaning of such
links. But the order in which such links are processed should still be as I
described above.

In other words, my proposal is:

1. Look for a link matching your requirements, if found, end.
2. If no link sufficiently matches your requirements, look for "XRD
includes". Process them in priority order from step 1.

> 3) OTHER XRD 1.0 ISSUES
> 
> Will and Eran to cover any other outstanding issues (such as the question of
> whether trust should be split into a separate spec?)

Since Will indicated he made great progress, I don't think we need to split
it at this point.

I agree that the signature element should be moved to the end.

We should have one XRD example before the schema description that shows all
the elements in action with minimal explanation, just as an easy reference
when reading the schema details. We should have a couple full examples in an
appendix.

I will work on a template example using a made up rel type and vocabulary.

> 4) LRDD - SUBJECT OF A HOST-META XRD
> 
> Eran: what's the status of this issue?
> 
>         http://lists.oasis-open.org/archives/xri/200907/msg00007.html

I think we are down to two options:

1. Define something like a <SubjectSet> element.
2. Define a LRDD extension to XRD that will define a <Host> element and a
simple rule how to apply the normal XRD trust model to it.

#1 means more work for XRD and some delay in getting this into the schema.
But if we get it right, it will be a useful facility for describing simple
resource sets.

#2 means a bit more work for parsers that implement LRDD to support an
extension element, but no changes to XRD are needed, and the solution only
addresses the single use case we have without overreaching.

I like one of these better but will wait to hear from others before I bias
the group...

> 5) OTHER LINK HEADER/HOST META/LRDD STATUS/ISSUES
> 
>         http://tools.ietf.org/html/draft-nottingham-http-link-header
>         http://tools.ietf.org/html/draft-nottingham-site-meta
>         http://tools.ietf.org/html/draft-hammer-discovery

Mark finished the new site-meta draft, changing focus to /.well-known/.
Should be posted before the IETF I-D cutoff next week. Mark also hopes to
push a final Link draft before the cutoff. A new discovery draft will be
published right after the cutoff, assuming there is an XRD draft to
reference.

EHL