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] RE: Difference between global and local subsegments (was RE: [xri] Increased complexity in resolver.)


Title: RE: [xri] Increased complexity in resolver.
Drummond,
 
I was trying to avoid the discussion about the + space not having a single global registry, so the flow I described was based purely on the structural/syntactic aspects of XRI. The silliness of the + namespace as a "Global" context symbol, when in fact there is no globally authoratative registry for stuff under "+", is something I just don't choose to worry about at this time. Time will tell if it turns into something useful or not.
 
You're taking this notion of xref/global-ref too far. I agree there should be a way for an identifier in context-A to be referenced in context-B. However, context-B must not reference identifiers that never exist in context-A. Context-B can associate its own data with a referenced identifier in Context-A, but it can't fabricate mythical identifiers in the Context-A namespace.
 

Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow - Cyber Identity Specialist
Computing Security Infrastructure
(206) 679-5933

 


From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Monday, April 30, 2007 8:10 PM
To: Schleiff, Marty; 'Steven Churchill'; 'Barnhill, William'; xri@lists.oasis-open.org
Subject: RE: [xri] RE: Difference between global and local subsegments (was RE: [xri] Increased complexity in resolver.)

Marty,

 

While I agree with you that in the resolution of @ootao+west*steve, @ootao can follow whatever policy it wants in resolving the global-xref “+west*steve”, I don’t agree that the steps you outline below are the only option. They are one option, but the steps I outlined are another equally valid option.

 

Specifically, you say that after resolving @ootao (we both agree that far), that @ootao must query the + registry for “west”, and then from that response, query the +west registry for *steve.

 

To begin with, the intention of the + space is that there is no single globally authoritative registry. It’s like dictionaries of the human language – with most languages (French being one notable exception) there are not just one authoritiative reference on the language. It’s all done by dictionary reputation & usage, i.e., for English, many people consult Webster’s or the Oxford English Dictionary, but no law decrees that they are authoritative.

 

So when I said that at step 4, @ootao queries @ootao+west for *steve, I was implying that @ootao is in fact authoritative for it’s own definition of “+west”. So it can query for that definition, and then query that result for *steve. However note that I did leave out one step. It should be:

 

1) Resolver queries @ for ootao

2) @ responds for ootao

3) Resolver queries @ootao for +west*steve

4) @ootao queries @ootao for +west

5) @ootao responds for @ootao+west

6) @ootao queries @ootao+west for *steve

7) @ootao+west responds for @ootao+west*steve

8) @ootao responds for @ootao+west*steve (i.e., responds to step 3)

 

Again, I think we do agree that when it comes to step 4, @ootao can follow its own policy about how it wants to return a result for +west*steve.

 

Now, let’s take a different GCS symbol, i.e., the example @ootao=steve*west. Here “=steve” is rooted in the global = registry. So how should resolution proceed/

 

My answer (which I believe addresses the other messages on this thread, which I’m just catching up on tonight) is identical to above:

 

1) Resolver queries @ for ootao

2) @ responds for ootao

3) Resolver queries @ootao for =steve*west

4) @ootao queries @ootao for =steve

5) @ootao responds for @ootao=steve

6) @ootao queries @ootao=steve for *west

7) @ootao=steve responds for @ootao=steve*west

8) @ootao responds for @ootao=steve*west (i.e., responds to step 3)

 

Now, the question is, because the = registry is involved, should @ootao respond to the query in step 4 by itself querying the global = registry for =steve? My answer is that while @ootao MAY implement such a policy, it is equally valid for @ootao to return a different answer than you would receive from querying the = registry for “steve’. Here’s the reason: @ootao is answering the question, “Please give me your XRDS for the resource identified as =steve”. Even though =steve (being a global XRI) is supposed to represent the same real-world resource no matter who you ask, that doesn’t mean that @ootao is required give you the same XRDS as you’d get from querying the = registry for “steve”. @ootao is totally within its rights to give you their own XRDS that represents the set of service endpoints (and/or other metadata) that @ootao knows about or has authorized =steve to register in their context. Or to give no XRDS at all, indicating that either @ootao does not “know” =steve, or that @ootao simply has no public relationship with =steve.

 

In sum, =steve as a global XRI is indeed intended to identify the same real-world resource everywhere, no matter what context in which it is used. However resolving =steve in different contexts (i.e., =steve, @ootao=steve, @cordance=steve, @oasis=steve) could all give different replies (or no reply) because each is supplying their own metadata view of =steve.

 

Hope this helps,

 

=Drummond

 


From: Schleiff, Marty [mailto:marty.schleiff@boeing.com]
Sent: Monday, April 30, 2007 8:05 AM
To: Drummond Reed; Steven Churchill; Barnhill, William; xri@lists.oasis-open.org
Subject: [xri] RE: Difference between global and local subsegments (was RE: [xri] Increased complexity in resolver.)

 

Hi Drummond (& All),

 

I gotta disagree with your logic about the resolution flow for "@ootao+west*steve", which you describe as follows:

1) Resolver queries @ for ootao

2) @ responds for ootao

3) Resolver queries @ootao for +west*steve

4) @ootao queries @ootao+west for *steve

5) @ootao+west responds for @ootao+west*steve

6) @ootao responds @ootao+west*steve

I suggest it goes more like this (steps 1-3 agree with Drummond):

 

1) Resolver queries @ for ootao

2) @ responds for ootao

3) Resolver queries @ootao for +west*steve

4) @ootao responds with whatever it pleases for +west*steve. Note that to determine its response, @ootao may, at its own option, choose to resolve "+west*steve" to help it figure out how to respond to the request in #3; however, @ootao is under no obligation to do so. If @ootao does decide to resolve "+west*steve" it would take the following steps:

4.a) @ootao queries + for west

4.b) + responds for west

4.c) @ootao queries +west for *steve

4.d) +west responds for +west*steve

4.e) @ootao considers, or ignores, or alters the response in 4.d to build its response to #3. 

Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow - Cyber Identity Specialist
Computing Security Infrastructure
(206) 679-5933

 

 


From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Sunday, April 29, 2007 11:40 PM
To: 'Steven Churchill'; Schleiff, Marty; 'Barnhill, William'; xri@lists.oasis-open.org
Subject: Difference between global and local subsegments (was RE: [xri] Increased complexity in resolver.)

Steve, Marty, Bill, et al:

 

It’s Sunday night, and after thinking about Steve’s observation over the last few days, I’ve come to a greater appreciation of the difference between global and local subsegments in an XRI authority segment. (Note that by “global subsegment” I mean the global-literal and global-xref rules on http://wiki.oasis-open.org/xri/XriCd02/XriAbnf2dot1, and by “local subsegment” I mean the local-literal and local-xref rules on that page.)

 

First, in XRI 2.0, an XRI authority segment consisted of only one global subsegment. It could contain any number of local subsegments inside it (and those could be either local-literals or local-xrefs), but it could not contain another global subsegment.

 

In the proposed XRI 2.1 syntax, an XRI authority segment can contain more than one global subsegment.

 

So what Steve noticed is that while the XRI resolution rules are the same for both 2.0 and 2.1, i.e., that a resolver just “walks the tree” of top-level subsegments in an XRI authority segment to resolve it, that tree of subsegments has one important structural difference: once you hit the first global-xref, every other top-level subsegment must be a global-xref.

 

In other words, think of the pattern this way:

 

1) XRI authority segments in XRI 2.0 (with the exception of cross-reference root authorities):

 

            GCS-char          local     local     local     …         /

 

2) XRI authority segments in XRI 2.1:

 

            GCS-char          local     local     local     …         global    global    global    …         /

 

I think this makes it easier to see that when you “switch over” from resolving local subsegments to resolving global subsegments, each global subsegment is relative to the previous one just like each local subsegment is relative to the previous one.

 

Secondly, when you apply that to Steve’s example – of resolving @ootao*west*steve and @ootao+west*steve, it’s true that the first one parses into four top-level subsegments…

 

            @

            ootao

            *west

            *steve

 

…and the second one into three…

 

            @

            ootao

            +west*steve

 

However, if the policy of @ootao is that *west and +west are synonyms, then @ootao*west can delegate to *steve and the same delegation can be recognized for @ootao+west*steve. Here’s the flow:

 

@ootao*west*steve

 

1) Resolver queries @ for ootao

2) @ responds for ootao

3) Resolver queries @ootao for *west

4) @ootao responds for @ootao*west

5) Resolver queries @ootao*west for *steve

6) @ootao*west responds for @ootao*west*steve

 

@ootao+west*steve

 

1) Resolver queries @ for ootao

2) @ responds for ootao

3) Resolver queries @ootao for +west*steve

4) @ootao queries @ootao+west for *steve

5) @ootao+west responds for @ootao+west*steve

6) @ootao responds @ootao+west*steve

 

Notice that it takes the same number of steps, for the same number of delegations, however @ootao is responsible for answering the +west*steve response, vs. the original client resolver being responsible for resolving it.

 

This ability to control who will provide the resolution response is, I believe, one of those key guidelines Marty is looking for (and which I am indeed tasked to elucidate) as to whether an XRI author should use local subsegments or global subsegments.

 

=Drummond (Note: I’m headed off early tomorrow morning for the Higgins f2f meeting in Austin, so I’ll be offline until mid-afternoon tomorrow.)

 

 


From: Steven Churchill [mailto:steven.churchill@xdi.org]
Sent: Sunday, April 29, 2007 10:12 PM
To: 'Schleiff, Marty'; 'Barnhill, William'; xri@lists.oasis-open.org
Subject: RE: [xri] Increased complexity in resolver.

 

 

> I know that Steve and I lost the "direct concatenization" vs. "compact syntax" vote, but I'd just

> like to point out that under compact syntax "@ootao+west" normalizes to "@ootao*(+west)". 

> And if "@ootao*west" and "@ootao+west" are declared as synonyms, then you could logically

> deduce that "@ootao*west*steve" and "@ootao*(+west)*steve" are synonyms. 

 

I agree. I’d just like to point out that the way that the two would be “declared as synonyms” is that “*(+west)” would be added as a local synonym to “*west”.

 

~ Steve

 

 


From: Schleiff, Marty [mailto:marty.schleiff@boeing.com]
Sent: Saturday, April 28, 2007 3:54 PM
To: Barnhill, William; xri@lists.oasis-open.org
Subject: RE: [xri] Increased complexity in resolver.

 

Hi Bill & Steve (& All),

 

I think Steve meant that EVEN IF "@ootao*west" and "@ootao+west" are declared as synonyms, then "@ootao*west*steve" and "@ootao+west*steve" are not synonyms (unless they are explicitly declared as synonyms).

 

I know that Steve and I lost the "direct concatenization" vs. "compact syntax" vote, but I'd just like to point out that under compact syntax "@ootao+west" normalizes to "@ootao*(+west)". And if "@ootao*west" and "@ootao+west" are declared as synonyms, then you could logically deduce that "@ootao*west*steve" and "@ootao*(+west)*steve" are synonyms. 

 

Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow - Cyber Identity Specialist
Computing Security Infrastructure
(206) 679-5933

 

 


From: Barnhill, William [mailto:barnhill_william@bah.com]
Sent: Saturday, April 28, 2007 9:36 AM
To: xri@lists.oasis-open.org
Subject: RE: [xri] Increased complexity in resolver.

 

Hi all,

Having just gotten back myself I also am trying to catch up.

Steve, can you explain what you mean by "even though
@ootao*west and @ootao+west are both synonyms."?

I thought the resolution sequence of subsegments to be the following after normalization:
@ootao*west => @, *ootao, *west
@ootao+west => @, *ootao, *(+west)
@ootao*(+west) => @, *ootao, *(+west)
@ootao(+west) => @, *ootao, *(+west)

Is this incorrect?

From what you said I got the idea that it's actually
@ootao*west => @, *ootao, *west
@ootao+west => @, *ootao, *west
@ootao*(+west) => @, *ootao, *(+west)
@ootao(+west) => @, *ootao, *(+west)

Which doesn't seem to make sense to me, so I'm betting I misunderstand.

Thanks,
Bill
-----Original Message-----
From: Schleiff, Marty [mailto:marty.schleiff@boeing.com]
Sent: Fri 4/27/2007 11:31 PM
To: steven.churchill@xdi.org; gabe.wachob@amsoft.net; xri@lists.oasis-open.org
Subject: Re: [xri] Increased complexity in resolver.

Hi All,

I'm just trying to catch up on this thread - I've been unavailable all week until now.

I think Steve is right. You can't have a top level local ref following a global ref, because it would end up being part of the global ref.

Even using parens, the closest you could come would be to have a local xref containing a global ref, with a local ref following the closing paren.

I don't envy Drummond for his task of providing guidelines describing when a minter should use local vs. global delimiters. I'll be amazed if he can do it (note that Drummond has amazed me more than once).
--------------------------
Sent from my BlackBerry Wireless Handheld


-----Original Message-----
From: Steven Churchill <steven.churchill@xdi.org>
To: 'Gabe Wachob' <gabe.wachob@amsoft.net>; xri@lists.oasis-open.org <xri@lists.oasis-open.org>
Sent: Fri Apr 27 18:17:48 2007
Subject: RE: [xri] Increased complexity in resolver.


Gabe,

Here's how the proposal would work I think: an authority that has a global
xref as a synonym may have local delegation beneath it (as in node C in my
diagram) but one cannot resolve "through" the global xref.  That's why I say
that @ootao*west*steve is not a synonym for @ootao+west*steve even though
@ootao*west and @ootao+west are both synonyms.

Thinking about it more, perhaps I was incorrect in my previous email: maybe
the resolver doesn't need to enforce the restriction after all, because the
parser's syntax tree cannot have a top-level local subsegment following a
top-level global xref.

Drummond, is this last statement true, or is there any way -- using parens
or what have you -- to do this?

~ Steve



-----Original Message-----
From: Gabe Wachob [mailto:gabe.wachob@amsoft.net]
Sent: Friday, April 27, 2007 5:48 PM
To: 'Steven Churchill'; xri@lists.oasis-open.org
Subject: RE: [xri] Increased complexity in resolver.

Steve-

Huh? Maybe because its Friday at almost 6pm, but I'm totally lost.

Why does the next sub-segment have to be a global xref?

        -Gabe

> -----Original Message-----
> From: Steven Churchill [mailto:steven.churchill@xdi.org]
> Sent: Friday, April 27, 2007 5:22 PM
> To: xri@lists.oasis-open.org
> Subject: [xri] Increased complexity in resolver.
>
>
> (Please refer to increased-complexity-in-authority-graph.doc. This is the
> same one I sent earlier.)
>
> So the resolver is walking across the top-level subsegments. It encounters
> a
> global xref, so it duly invokes the authority resolution service (of the
> previous subsegment). It gets back an XRD. Now the resolver needs to
> evaluate the type of the next subsegment -- if it's another global xref
> then
> it can continue walking. Else it has to error out.
>
> I would sure hate to see that type of logic in the resolution spec.
>
> ~ Steve
>
>
>
> -----Original Message-----
> From: Steven Churchill [mailto:steven.churchill@xdi.org]
> Sent: Wednesday, April 25, 2007 3:33 PM
> To: 'xri@lists.oasis-open.org'
> Subject: FW: [xri] Flat structure for local delegation within global xrefs
>
>
> I think I've managed to confused everyone (again) by sending the wrong
> document.
>
> The attachment increased-complexity-in-authority-graph.doc summarizes my
> discussion with Drummond yesterday. For one thing, I fear that we've
> redefined the meaning of the term "XRI synonym". In the diagram you will
> note that when adding the localID "+west",  @ootao*west is (still) a
> synonym
> for @ootao+west (they resolve to the same XRD), but @ootao*west*steve
> would
> no longer be a synonym for @ootao+west*steve.
>
> The other attachment (increased-complexity-in-authority-graph-
> flatness.doc)
> talks about the flat structure for local delegation within global xrefs.
>
> ~ Steve
>
>
>
> ________________________________________
> From: Steven Churchill [mailto:steven.churchill@xdi.org]
> Sent: Wednesday, April 25, 2007 3:22 PM
> To: xri@lists.oasis-open.org
> Subject: [xri] Flat structure for local delegation within global xrefs
>
> (Blech.)
>
> Please see attached.
>
> ~ Steve
>



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