[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Re: [Openxri-users] Thoughts about XRI aliases
Markus, These are all good questions that you ask.
Keep ’em coming. My comments in ###. From:
markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] On Behalf Of Markus Sabadello Hey :)
One of the main problems with the OpenXRI server is that it currently
has no support at all for CanonicalID and i-numbers. Instead it uses
stupid-looking URNs to identify authorities. ### Conceptually, a given instance of the
OpenXRI server hosts a subgraph of the entire authority resolution graph. If
you want the OpenXRI server to be capable of hosting subgraphs that validate
under CID verification, then it needs to be capable of producing XRDs
containing <CanonicalID>s that have a delegation path up to one of the GRS
roots. If the OpenXRI server is not capable of hosting CID-verifiable
subgraphs, then I would challenge its usefulness. Another problem in the OpenXRI server (and in my way of thinking) may
be the term "aliases". Please let me know if the following is
consistent with the XRI synonym mechanisms: For example, it is possible with
OpenXRI to set up @free*a*b and @free*x*y*z and @free*c and @free*d to all
share the same authority and therefore all SEPs. But no <Ref>
is involved in any of the XRDs here. So the OpenXRI server can basically model
a polyarchical relationship without <Ref>s. Is this behaviour incorrect?
I am beginning to think that this is wrong. ### Under CID verification, XRI’s @free*a*b
and @free*x*y*z and @free*c and @free*d cannot return an XRD with the same CID,
unless they use Refs. Thus the XRIs CANNOT be synonymous under CID
verification. (The word “alias” seems to be another synonym for “synonym”. The
XRI Resolution Spec should (Drummond) define the word “synonym” in order to
avoid this confusion.) Despite all this, I am still saying (as in my first mail) that a piece
of information is missing in the OpenXRI store and that there needs to be
a way of telling OpenXRI that two namespaces (i.e. root authorities from
OpenXRI's point of view, such as @free and @on-line) share the same
authority. ### As I mentioned above, they cannot share
the same authority under CID verification without using a Ref. [As I mentioned
in my previous “bitch” email, they can always share the same authority by
setting the $res*auth SEP URI for @free to the corresponding value in @on-line,
but such a graph is not cid-verifiable. Gabe and I disagree as to whether such
graphs are “noise” are not.] If you don't agree with that, tell me how to solve these 2 problems: ### Markus, if you still have issues
after the above, then please re-ask the questions, and I will respond. 1) I-services: The contact page specification says that a contact
page can either be bound to an authority or to a QXRI. On freexri, both is
possible. So I decide to set up an authority-bound contact page for @free*x. Now
someone tries to access @on-line*x. How does my contact page
i-service (which has access to my OpenXRI store) look up the right contact
page? I know, the correct way would be to perform XRI resolution on @on-line*x
and look at the CanonicalID. But this is overkill, since I already know that
@free and @on-line share the same authority, and if there was a way of
configuring my OpenXRI server to "know" this, then I could simply
look into the store and conclude that @free*x and @on-line*x are the same. 2) For a given QXRI that resolves to an authority in my store, I want
to find other QXRIs that also resolve to it. This works fine for @free*x and
@free*y, since the store knows that *x and *y share the same authority. But how
do i know that @free*x and @on-line*x share the same authority? Again, there
needs to be a way to add the information to the OpenXRI store that its
"root authorities" @free and @on-line are the same. Markus P.S.: If anyone wants to look into the details of the OpenXRI
store, I can of course give you mysql access to the freexri database. On 5/11/07, Steve
Churchill <steven.churchill@ootao.com > wrote:
Markus and all, The XRI authority graph model is neither fuzzy nor ambiguous.
On the contrary, it is formal and verifiable. [The problem, for everyone, is
that we have left the graph model to be reverse engineered by the audience of
the XRI Resolution Spec, but more about that below.] Consider this example: I can set my XRD for =steven.churchill
so that its $res*auth SEP points to the same URI as does the $res*auth SEP for
@free. If I do this, then =steve*<name> will successfully resolve for any
<name> in @free's namespace. (You can try this little exercise to see if
I'm lying.) The important thing is that all this type of crap just
doesn't matter! The XRI authority graph resulting from this little exercise is
not verifiable, and thus whatever results from XRI resolution is just
"noise" in the XRI space. But if you don't look at the problem
from a graph perspective, then it becomes really hard to see this. I repeat (to
everyone in this TC) if you don't look at the problem from a graph perspective,
then it becomes really hard to see this. Conversely, if you look at XRI authority resolution from the
standpoint of having a formal graph model, then the only questions are
"what is the definition of the graph" and "how is a valid graph
verified". This is well defined and formal. You can read about it in my
articles on CanonicaIID verification at http://dev.inames.net/wiki/XRI_CanonicalID_Verification. Markus, I suggest that you look at your 3 questions from the
perspective "do these scenarios result in verifiable XRI authority
graphs?" If you do (and once you are familiar with the graph model) then I
think you will see that the fuzziness goes away. ~ Steve PS: Drummond, the confusion of this thread arises largely
because we HAVEN'T formalized the authority graph model in the XRI resolution
spec. Again, we are forcing the abstract model to be reversed engineered from
the specification. Very bad. To answer questions such as Markus's outside of
the context of the formal XRI graph representation is mostly an exercise in
confused terminology and wasted time (such as this thread.) But alas, I've
complained about this on several occasions to no avail. From: openxri-users-bounces@lists.sourceforge.net
[mailto:openxri-users-bounces@lists.sourceforge.net ] On Behalf Of Markus Sabadello Question
3: A "namespace"
in OpenXRI terms is an entry point into the realm of the store. Its authority
lies outside the store (e.g. still at the i-broker), but it can act as a parent
authority inside the store. In contrast, a "subsegment" in OpenXRI
terms has both a parent authority and an authority inside the store. So if I
host @free*x at my OpenXRI server, then I have the following things in my
store: - The
namespace @free associated with an authority 1 - The
subsegment *x with parent authority 1 and authority 2 In total
one namespace, one subsegment, and two authorities. Now If I
want to register @free*y as an alias for @free*x, I simply put the following in
the store - The
subsegment *y with parent authority 1 and authority 2 But I can
do nothing to tell my store that it is also responsible for @on-line*x and
@on-line*y. For that I would need a method to associate another namespace with
authority 1. Markus On
5/10/07, Gabe Wachob < gabe.wachob@amsoft.net>
wrote: You ask good questions. These are explicit design
requirements that many people have forgotten about. Answer to Question 1: Nothing wrong – this is totally
anticipated. I don't know that we have a term, but yours seems OK. Answer to Question 2: Nothing wrong – this it totally
anticipated. The name sounds fine. Answer to Question 3: I don't understand the
difference between namespaces and subsegments – each subsegment defines a new
namespace… so maybe there's something else here?
But
before I do this, I would like to hear someone's opinion. Bill?
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]