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] Link processing rules and linked XRDs (was: Delegation Terminology / Linked XRD)


I would add a third rule: The loop-detection rule.

If XRD1 links to XRD2, then it's possible (and maybe even good practice?) that XRD2 links to XRD1. So a resolver must keep a list of which XRDs it has already visited. It needs that list anyway for the backtracking rule.

Markus

On Thu, Jul 9, 2009 at 7:36 AM, Drummond Reed <drummond.reed@cordance.net> wrote:
I feel pretty strongly about the advantages of the priority-based link
processing rule, i.e., that an XRD processor should process the links in
XRD1 in priority order until it either finds the related resource it is
looking for or exhausts all links in XRD1.

This means that if, following priority order of links in XRD1, the processor
reaches a linked XRD (call it XRD2), the processor should then halt further
processing of links in XRD1, fetch XRD2, and continues recursively, i.e.,
processes XRD2 links in priority order until the related resource is
discovered or the links are exhausted.

This model includes two other rules:

1) The backtracking rule, i.e., if the links in XRD2 are exhausted with no
success, the processor returns to the rest of the links in XRD1 and
continues in priority order until either: a) the related resource is found,
b) another XRD (XRD3) is followed, or c) the links are exhausted and the
process terminates. This rule is applied recursively (to XRD2, XRD3, etc.)

2) The equal priority rule, which is that anytime two or more links have the
same priority, the XRD processor MUST choose among them randomly. This gives
you a simple form of round-robin capability.

I won't be on the call tomorrow, but I hope this helps with the discussion.

=Drummond

> -----Original Message-----
> From: Will Norris [mailto:will@willnorris.com]
> Sent: Wednesday, July 08, 2009 3:10 PM
> To: XRI TC
> Subject: Re: [xri] Delegation Terminology / Linked XRD
>
> Forgot to reply to this earlier in the week, but we do need to wrap up
> this discussion and decide how to move forward...
>
> I agree that this is an absolutely valid model, and was actually the
> first one I envisioned.  One thing to take into consideration when
> flattening these XRDs is what to do with the Link priorities.  What if
> XRD1 has two related resources, an OpenID provider with priority of 5,
> and another XRD with priority of 10.  That linked XRD, XRD2, also
> lists an OpenID provider with a priority of 1.  So which OpenID
> provider should be used first?  The one with priority of 1, because it
> has the lowest priority value?  But the linked XRD had a priority of
> 10... is that taken into consideration when determining the "effective
> priority" of resources linked from that XRD?  There are a couple of
> different ways to answer it, but my point is that you will probably
> want to be explicit in how applications should handle this to ensure
> consistent behavior.
>
> The second problem with this approach is that you end up fetching
> every XRD for the resource every time, even if the highest priority
> <Link> ends up being in the first document.  I don't anticipate people
> going too crazy with linked XRDs, but it is certainly a practical
> deployment issue we should consider.
>
> With the proposed approach of sorting by priority first, and then
> fetching linked XRDs as necessary, it solves both the question of how
> to handle "effective priority" as well as "just in time fetching" of
> linked XRDs.  It certainly changes how we need to word the priority
> attribute section, since it assumes you're sorting a pre-filtered set
> of elements.
>
> -will
>
>
> On Jul 4, 2009, at 10:46 AM, Eran Hammer-Lahav wrote:
>
> > My point is that if you draw a graph of the resource and all its
> > links from the various sources and XRDs, it looks like you should
> > flatten the content of XRDs, not search them in order...
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: Will Norris [mailto:will@willnorris.com]
> >> Sent: Friday, July 03, 2009 11:25 PM
> >> To: XRI TC
> >> Subject: Re: [xri] Delegation Terminology / Linked XRD
> >>
> >>
> >> On Jul 3, 2009, at 5:11 PM, Eran Hammer-Lahav wrote:
> >>
> >>>> Well there is a precedence.  Even though a XRD-linked XRD shares
> >>>> the
> >>>> semantics as one linked from an HTTP header, we can't ignore the
> >> fact
> >>>> that <Link> elements do in fact have a priority.  I remember that
> >>>> LRDD
> >>>> specifically stated that determining which one of multiple
> >>>> describedby
> >>>> links should be used was application specific.  And that seems to
> >>>> make
> >>>> sense because there is no good deterministic way to order them.  We
> >>>> can order <Link> elements though, so it makes sense to respect
> >>>> their
> >>>> order.
> >>>
> >>> I agree that Link priority must take precedence but that's the easy
> >>> case. What happens when all priorities are equal.
> >>
> >>
> >> If a linked XRD is really just another linked resource, then the spec
> >> instructs consuming applications to choose randomly.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this mail list, you must leave the OASIS TC that
> >> generates this mail.  Follow this link to all your TCs in OASIS at:
> >> https://www.oasis-open.org/apps/org/workgroup/portal/
> >> my_workgroups.php
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




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