This thread is becoming impossible to follow…
I’ll start a new one with shorter questions…
EHL
From: Dirk Balfanz
[mailto:]
Sent: Friday, September 18, 2009 9:44 AM
To: Eran Hammer-Lahav
Cc: Breno de Medeiros; XRI TC
Subject: Re: [xri] RE: #next: alternate to #replace
On Fri, Sep 18, 2009 at 9:28 AM, Dirk Balfanz <> wrote:
On Thu, Sep 17, 2009 at 9:41 PM, Eran Hammer-Lahav <>
wrote:
I don't think the fact that a
consumer can find multiple descriptors for a single resource matters much. It
can find descriptors using multiple links, multiple discovery protocols, and
even descriptors in multiple formats. There is a lot that can be said about resources.
When it comes to XRD, a consumer always starts with a single XRD document. XRD
has no opinion about what a client should do when encountered with multiple
'describedby' links. That is up to applications to decide. Trying to create a
world in which you "first gather everything you know about a resource into
a big complete collection" is impractical.
But within a single XRD root document, when following a single 'describedby'
link, consumers must get consistent results when asking the same question. That
is an absolute requirement. In other words, if different consumers ask the same
XRD the same question, the answer must be the same. How you obtain the first
XRD matters, but it doesn't change the answer (it might make the answer
'trusted' or 'not trusted', but it is still the very same answer).
An XRD is a data set which consumers can query for data. The two main queries
you make against this data set are:
1. Give me the list of all resource attributes in the order they appear.
2. Give me all the linked resources that match a criteria, in the order they
appear.
XRD processing is limited to the processing of information found by starting
with a single XRD document. How you consolidate information gathered from
multiple XRDs or discovery sources is completely out of scope. What is also out
of scope is what a consumer should do when an XRD contains another
'describedby' link to another XRD. From a process standpoint, this is exactly
the same as finding another XRD elsewhere for the same resource.
The reason why we are discussing including some other processing directives
such as #see-also or #replace is because we are a clear use case for managing
the deployment of a single root XRD across multiple documents. From the
perspective of the consumer obtaining the root XRD, it is a single document.
Otherwise I agree with you that we end up with a mess because we have an
inconsistent model of when we take into account other descriptors and when we
don't, and it doesn't add up to the same view.
When a C complier is processing project files, it usually comes across the same
include file many times. But as far as the complier is concerned, it is working
with a single document at a time. The include directive (which are often
conditional) are used to construct the actual source code the complier sees. C
include files are in no way atomic units. Only the root document after fully
expanding all includes is the atomic unit used to create an object file.
Sorry - I'm joining the discussion late.
This is the right metaphor for XRD. You start with a single
XRD and a single Subject and whatever else you drag in there from other XRD
documents must be viewed as part of that root XRD.
This "includes" semantic doesn't make sense to me
(neither does the "next" semantics, btw): If the
"root" XRD has Subject Foo and the "included" XRD has
Subject Bar, then these two XRDs talk about two different resources, and
shouldn't be considered part of each other. What I had in mind when I asked for
this "see-also" link was just a way to give a hint to the resolver
where there might be other places where the XRD it's looking for could be
found. Normally, we find the XRD in well-defined places like
.well-known/host-meta or pointed to by Link: headers, etc. but if for some
reason that is not where you have your actual XRD, and it is inconvenient for
you to move your XRD there, then you can use the see-also link to point to the
place where your XRD _really_ is.
Now, the resolver knows two things: (1) which resource it's
performing discovery on, and (2) what kind of meta-data it's looking for. I'm
imagining resolvers hunting around, and following #see-also links until they
find an XRD that (1) is about the resource they're interested in and (2)
contains the meta-data they're looking for. If the root XRD is about a Subject
that's not what you're resolving against but has a #see-also link, that's fine
- perhaps the Subject in the XRD pointed to will be what the resolver is
looking for. Similarly, if the Subject of the root XRD is correct but there is
no Link in there with the right meta-data, try some of the #see-also links and
see whether you can find the meta-data there.
The notable exception would be webfinger, which only worries
about (1) which resource it's performing discovery on, and wants to collect
_all_ meta-data about that resource. So webfinger would have to follow all
those #see-also links and accumulate the meta-data across all the XRDs it finds
that way, as long as they have the right Subject.
To be honest, in our use case (hosted OpenID providers) we
need the #see-also only in host-metas. It was a way for people who are too dumb
to sign their host-meta to delegate everything, even the hosting of the
host-meta, to their hosting provider. If you _can_ sign your own host-meta,
then the delegation mechanisms afforded by TargetAuthority[1] and URITemplate
are sufficient to point to the next XRD and establish the trust chain that way.
Of course, that doesn't work if there is other use cases that need the #see-also.
I'm gonna pull a Breno here and re-write this paragraph. :-)
What wouldn't work, if other people had use cases for #see-also, is its removal
from the XRD spec, _not_ the TargetAuthority/URITemplate delegation mechanism.
That, of course, will continue to work, if other people had uses cases for
#see-also.
Dirk.
So, perhaps in the same spirit as we solved the whole
subject-for-hosts problem, perhaps we can just remove this from XRD altogether
and make something like this part of host-meta?
Dirk.
[1] I just noticed that that went away. What on earth
happened to it? We need different TargetAuthorities for different Links!
If you consider the importance of document order, it is
clear that the order in which an XRD is included changes its meaning. So again,
this has nothing to do with trying to build a complete view of resource
descriptors, but still only a single view, that of the root XRD.
I don't think we are likely to solve the problem of consolidating multiple
descriptors for a single document anytime soon. This comes up daily when
discussing link relations, how to pick links when more than one is present, how
to pick links when no link provides the perfect combination of attributes, how
to handle links in multiple transports, and what to do when the information
contains conflicts. This is all very early and we must let individual protocols
solve this.
What we can and must do is make sure that within a single thread of discovery,
that is, a single XRD root document, we have clear and predictable processing
rules. That is the only problem we are tasked to solve.
The use case for spreading a resource descriptor over multiple XRD documents
(with a single root) is clear. The question is now finding the right balance
between implementation complexity and deployment flexibility. This is not a new
challenge. Almost everything we do here is dealing directly with that (see
signatures, trust, priority, etc.).
EHL
> -----Original Message-----
> From: Breno de Medeiros [mailto:]
> Sent: Thursday, September 17, 2009 9:00 PM
> To: Eran Hammer-Lahav
> Cc: Drummond Reed; XRI TC
> Subject: Re: [xri] RE: #next: alternate to #replace
>
> Okay, I had some more time to reflect about this.
>
> I am now of the opinion that incorporating <Type> from more than one
> XRD is either wrong or at least not robust. The reason is that we have
> written a spec that includes elements such as <Subject> which allows
> an XRD for a resource to be resolvable from more than one location and
> talk about the same resource. A corollary is that the meaning of an
> XRD document should _not_ depend on the flow used to discover it.
> There may be several flows leading to it, it should not matter.
>
> You can say, what about trust? Doesn't it depend on the flow. Yes, it
> does, but trust _is_ a property of the flow, not of the resource.
> Besides, it has only one of a small set of restricted values.
>
> That means that a the last XRD found to describe a resource must be
> atomic. It can't depend on earlier XRDs. Any type of include would
> violate this assumption which I thought had been fairly fundamental in
> how we designed this whole architecture.
>
> My conclusion is that <Type> cannot flow from more than one XRD.
> Neither can Links for that matter. XRDs are independent things, like
> resources all onto themselves. That is a consequence of they being
> flow-independent.
>
> Taking that as a start point, the outcome of processing a #see-also is
> that XRD discovery would produce _two_ independent XRD documents. A
> client could pick and choose the one XRD that satisfies its needs, but
> could not merge or co-mingle them in any form.
>
> Of course, if we are willing to accept that a resource can have two
> distinct XRDs, then by subsequent branching any number is already
> possible, which means that no simplification would be achieved by
> restricting #see-also to a single occurrence.
>
> I am not sure allowing multiple XRDs to describe a single resource is
> too far a departure either. Fully embracing the concept that XRD is
> flow-independent means that there may be more than one XRD for a
> resource in any case, discoverable through different routes.
>
> Am I wrong, or is XRD discovery a schizophrenic where resources have
> multiple-personality disorder?
>
> a #replace semantics that means, trash this XRD, take that one.
>
> a multiple value #see-also directive that says: I am a schizophrenic
> resource with multiple personalities. Pick one.
>
> If we prohibit #see-also we make processing easier, but the resources
> are still potentially schizophrenic because XRDs can pop up in
> expected places.
>
>
>
> On Thu, Sep 17, 2009 at 7:33 PM, Eran Hammer-Lahav
> <>
wrote:
> > Forget about 'required' for a second. If that is the only issue we
> have I will be happy to drop it. The use case for it is that sometimes
> it is unsafe to interact with an endpoint if its attributes are known.
> It is the only way to "break" client from trying out talking to
an
> endpoint they *think* they understand but that requires an additional
> add-on. This came up in OAuth discovery for requiring certain crypto
> extensions (that without would not be secure enough). This is not a
> blocking use case.
> >
> > Back to the main issue.
> >
> > I don't see how this is not just an include? A client looking to
> learn about the resource attribute must still load and process each
> #next XRD. If I want to write a client that loads XRD information into
> memory, and then query that information as needed later, I will need to
> load multiple XRD documents, process them, combine the information into
> another flat container, and then search that.
> >
> > If there is only one XRD, I can just use the XML document object as
> my memory store. As soon as I have attributes coming from multiple
> documents, the client gets more complex. It doesn't matter if it is two
> or two hundred chained XRD.
> >
> > Most XRD will be processed in three phases:
> >
> > 1. Load into memory
> > 2. Review for known attributes (Type, XRD-level stuff)
> > 3. Link selection
> >
> > #see-also and #next work well for #3 because the client *knows* what
> it is looking for and can stop as soon as it finds it. So it can load
> one document at a time, search it, and move on. They don't work for #2
> without going through *all* the documents.
> >
> > The real question is how important is the include use case. If it is
> a critical feature, then the cost on clients doesn't really matter. It
> is just the cost of doing business.
> >
> > EHL
> >
> >
> >
> >> -----Original Message-----
> >> From: Drummond Reed [mailto:]
> >> Sent: Thursday, September 17, 2009 6:40 PM
> >> To: 'XRI TC'
> >> Cc: Eran Hammer-Lahav
> >> Subject: #next: alternate to #replace
> >>
> >> In today's (sparsely-attended) telecon we made a crucial decision
to
> >> remove
> >> #see-also links between XRDs in favor of #replace links.
> >>
> >> The rational was simple: this is the only XRD linking model that
> lets
> >> us
> >> keep the XML processing very simple: just load the XRD into an
XML
> >> parser,
> >> query its elements/attributes as needed, and get on with your
> business.
> >> There is none of the "include" functionality that
#see-also implies.
> >> With
> >> #replace links, an XRD consumer simply checks at the start of XRD
> >> processing
> >> to see if there is a #replace link. If so, it replaces the
current
> XRD.
> >> If
> >> not, it knows it has only one XRD to look at.
> >>
> >> I've been cooking on it since the call, and I feel uneasy about
this
> --
> >> not
> >> because it doesn't produce a cleaner, faster XRD processing
model,
> but
> >> because it prohibits what I believe will be a very common XRD
> >> delegation
> >> pattern: having a "local" XRD that specifies certain
common links an
> >> author
> >> might want to have very tight control over, but which then
delegates
> to
> >> a
> >> "hosted" XRD to handle everything else. Typical
example: a blog
> owner
> >> that
> >> wants to control certain resource properties and links from
his/her
> own
> >> local blog XRD (for instance the mgmt interface might be right
> inside
> >> WordPress), and then delegates to an XRD host like Google or
Yahoo
> for
> >> everything else.
> >>
> >> #replace does not support that model.
> >>
> >> So here's an alternative I'll call #next. #next does NOT have
> include
> >> semantics. Instead it's "goto" semantics, i.e.,
an XRD consumer
> simply
> >> follows sequential processing of the elements in the first XRD
> element
> >> if/until it encounters a #next link (it doesn't even have to look
> ahead
> >> through the XML tree to see if there are any #next links). Once
it
> >> encounters a #next link, at that point it stops and loads the
linked
> >> XRD,
> >> confirms it is valid, and continues processing from there (and
DOES
> NOT
> >> ever
> >> backtrack again to the previous XRD).
> >>
> >> The only thing the #next processing model requires is an
adjustment
> to
> >> processing of required Type elements. There are two options for
> this:
> >>
> >> 1) Drop the "required" attribute on Type. What is the
use case for
> >> this?
> >> Should XRD discovery really halt if an XRD consumer does not
> understand
> >> a
> >> particular Type? Or can this form of type-checking be handled at
the
> >> application layer?
> >>
> >> 2) If we keep the "required" attribute on Type, then
make it apply
> per-
> >> XRD.
> >> By this I mean that the XRD processor only looks at required
<Type>
> >> elements
> >> on a per-XRD basis. For example, if it does not find a required
> <Type>
> >> element it does not understand in XRD #1, it processes it. Then,
if
> it
> >> encounters a #next link, it moves to XRD #2, and applies the same
> rule.
> >> It
> >> stops only if it encounters an XRD with a required <Type>
element it
> >> does
> >> not understand.
> >>
> >> All this means is that if there is a required <Type> that
applies to
> a
> >> resource in all contexts, then it must appear in all XRDs that
> describe
> >> the
> >> resource. That does not seem like an unreasonable requirement for
> XRD
> >> providers at all, especially if that's all we need to do to
preserve
> >> the
> >> ability to delegate an XRD without giving up all local control.
> >>
> >> In sum, #next preserves the ability to walk a directed graph of
> XRDs,
> >> moving
> >> from each to the next, without having to complete replace each
one.
> Of
> >> course it also gives us #replace semantics if the only link in
the
> >> source
> >> XRD is a #next link.
> >>
> >> BTW, I agree with Eran that the rule should be: multiple #next
links
> >> are
> >> allowed but are only processed if the previous #next links fail
to
> >> produce a
> >> valid XRD. Otherwise they are ignored. This keeps it simple.
> >>
> >> Thoughts?
> >>
> >> =Drummond
> >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
---------------------------------------------------------------------
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
