OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xri] Linked XRD Processing Rules

Reply inline to Eran's questions.

> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> Sent: Friday, September 18, 2009 9:57 AM
> To: XRI TC
> Subject: [xri] Linked XRD Processing Rules
> The questions we need to answer in order are:
> - Is there a need for general purpose processing rules to link one XRD to
> other XRDs?

Yes. Dropping XRI linking altogether prevents any form of XRD delegation. I
belive that Dirk was arguing that such delegation is really only needed in
/.well-known/host-meta XRDs. That may be true, but I'm not sure what
mechanism he's proposing for doing that there -- isn't that an XRD?

Also, I don't believe delegation is not just an OpenID use case. For
example, blog owner use case I cited earlier could apply to many services
besides OpenID.

> - If yes, is a #replace directive enough, or do we need #include?

My answer is that #replace is not enough, but #include is too much.

1) #replace only supports all-or-nothing delegation. There is no "local
override". Although I would vote for this before giving up on delegation
altogether, there is an improvement that still supports local override
without going to #include.

2) #next (or whatever other name we might want to use for this) is "ordered
XRDs". Scott and I appear to see this the same way: each XRD is atomic, and
is processing independently according to the same rules (including Type
selection). There is no aggregation or "include" functionality. The rule is
simply that when you reach a #next link, the XRD consumer fetches the next
XRD and confirms that it is valid. If so, it drops the first one and
processes the second one.

This XRD linking model supports the same delegation option as #replace, but
adds the ability for the first XRD to include links that override those in
the #next XRD because they will be processed first.

As Scott points out, it has no effect on <Type> selection, because the XRDs
are atomic and processed independently.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]