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] CanonicalID verification text for section 11.


Title: RE: [xri] CanonicalID verification text for section 11.

<<...>>

Markus and Drummond,

Markus, thanks for the valuable input. Ive attached the revised version of the text. My comments are in ###.


- The priority attribute for LocalID and CanonicalID should be mentioned in section 3.3.3 ("Priority Attribute") and maybe also in 3.2.3 ("Authority Synonym Elements").

### I will leave this change to Drummond, since it is outside section 10.

- Lines 81-82: I think this is only true if it is not the local canonical identifier itself that is resolved. For example, in figure 11-2, if I resolve =!1, then I think I should get * jane.doe in the <LocalID>, not !1.

### An authority resolution service (its registry) may have many local synonyms defined for a given parent-child hierarchical relationship (for example, *jane.doe, *jane, *jd.)  So which one should it pick for its <LocalID>? In the general case it can put anything it wants in the LocalID. The question becomes: what should it do in the cid=true case? I believe that the same should probably apply: that is, it can put anything it wants. I have therefore revised the text to say that the local canonical identifier may be returned in the <LocalID> field. Drummond and others, please respond if this does not seem correct.

- Lines 153-155: Same as above.

- Line 82: A small typo, "LocalId" should be "LocalID"

### Got it, thanks.

- Lines 151-152: "There must be at least one local canonical identifier for each parent-child relationship"... Maybe add something like "...in order for the graph to be verifiable"? After all, the <CanonicalID> is still optional.

###  I have added text to point this out. (But it presents an interesting problem for the entire section, because pretty much all of the text in this section only applies under CID verification. Its awkward to keep pointing it out in multiple places.)

- Line 18: Shouldn't this say xrd:XRD/xrd:Service/xrd:ProviderID instead of xrd:XRD/xrd:ProviderID ?

### No. Is the XRD scoped ProviderID that is used here.


- One thing that sounds a bit strange to me is that you always speak of "synonyms" even if there is only a single subsegment that establishes a parent-child relationship. For example, 11.2.7.1 says "there must be at least one local synonym for each parent-child relationship". Is it still called synonym if it's only one? But I guess that's only a detail..

### Its a good point.


I also have a very non-technical question.. Line 9 says "These replacement semantics are clearly not parent-child semantics"... Then what does it actually mean to use Refs? Assume I am an ordinary user who has no idea how XRI works, and I have two i-names =ms and @id*markus, which I want to be synonyms. How do I decide which one is the "original" "hierarchical parent-child" authority, and which one is "just" the Ref-using synonym?

### Very good question. The hierarchical parent-child relationships (the black edges) are determined solely by the authority resolution services (parent nodes) that decide to answer queries for local synonyms. Let me try to draw the black edges.

     o [=]                     o [@]
     |
                         |
     |
*ms                     | *id
     |                         |

     o [
=ms]                   o [@id]
                               |
                               | *markus
                               |
                               o [@id*markus]

The black edges (shown above) are determined by the fact that a given authority resolution service (such as [=]) returns a (non-failure) XRD when queried for a local synonym (such as *ms.) To repeat myself: the black edges are determined by the behavior of the authority resolution services. For example, if you query @ids auth-res-service for *markus, and it returns an XRD (containing a verifiable CID, because this is the Canonical ID Verification model) then a black edge exits for the local synonym *markus.

As you know, the polyarchical parent child relationship (say between [@id] and [=ms]) is established by placing a Ref from [@id*markus] to [=ms].

Keep the great questions coming.

~ Steve

On 6/2/07, Steven Churchill <steven.churchill@xdi.org> wrote:

Drummond,

 

Attached are my changes for section 11.

 

I still owe the changes for Appendix E. (These are small.)

 

~ Steve

 





--
@freeXRI /
freexri.com / try free i-names

wd11-cid-verification-v02.doc



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