[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] ED04 synonym proposal (was RE: [xri] CID changes in wd11)
I would agree with this but the proposal seems to take it further. contact: =les sip: =les/(+phone) chat: =les/skype/chat > -----Original Message----- > From: Tan, William > Sent: Monday, August 20, 2007 6:47 PM > To: Chasen, Les > Cc: Drummond Reed; Markus Sabadello; Gabe Wachob; Davis, Peter; William > Barnhill; steven.churchill@xdi.org; XRI TC; Andy Dale > Subject: Re: [xri] ED04 synonym proposal (was RE: [xri] CID changes in > wd11) > > I would say that the resolution spec simply provide the capability of > expressing "I would like to map to this other identifier" and "I allow > this other identifier to map to me". It is then up to the client to > define what the verb "map" means. Note that the resolver can still > verify the mapping even though it doesn't dictate what "map" means. > > =wil > > Chasen, Les wrote: > > > > There is a big difference between doing some analysis and analysis > > paralysis. We are trying to put this particular proposal to bed in a > > matter of days. I am not against it just pointing it out. > > > > When a web site is migrated to another domain more is done then just a > > redirect. It seems strange to say that mapToId tells the consuming > > application to replace his existing identifier with the identifier > > pointed to by the mapToId when there is nothing in the resolution spec > > that says that the original XRD can no longer be used. If XRD A maps > > to XRD B that tells the consuming application to replace the > > identifier for A to B. However, all the services in A continue to > > resolve normally. With this proposal, do we need to re-look at service > > selection? Yuck I hope not. > > > > contact: =les <http://xri.net/=les> > > > > voice: =les/(+phone) <http://xri.net/=les/%28+phone%29> > > > > chat: =les/skype/chat <http://xri.net/=les/skype/chat> > > > > pibb me =les/+pibb <http://xri.net/=les/+pibb> > > > > ------------------------------------------------------------------------ > > > > *From:* Drummond Reed [mailto:drummond.reed@cordance.net] > > *Sent:* Monday, August 20, 2007 4:07 PM > > *To:* Chasen, Les; 'Markus Sabadello'; Tan, William > > *Cc:* 'Gabe Wachob'; Davis, Peter; 'William Barnhill'; > > steven.churchill@xdi.org; 'XRI TC'; 'Andy Dale' > > *Subject:* RE: [xri] ED04 synonym proposal (was RE: [xri] CID changes > > in wd11) > > > > First, metapoint: Les has a good point he says, "I fear that there are > > some nuances that will not get uncovered because we are out of time to > > really think about this from all angles". That's a problem anytime we > > introduce new XRD elements. It is only with experience that all their > > nuances can get discovered. However if that prevented us from adding > > new elements, we'd be stuck in "analysis paralysis" and never do > anything. > > > > The situation now is that, if we want to keep LocalID, CanonicalID, > > and Ref all with their current semantics (and in fact tighten down the > > semantics on Ref), we still need a way to express equivalence > > relationships. > > > > I just had a good talk with Markus discussing why I believe both > > EquivID and MapToID/MapFromID are needed. As I think we all agree, > > EquivID establishes pure peer-to-peer identification synonymity. > > Markus points out that the priority element can be used to rank > > EquivIDs so that a consuming application can even understand which is > > the preferred peer synonym. > > > > But EquivID has no semantics regarding replacing one ID with another > > one (and I wouldn't want to overload it with such, for the same reason > > we don't want to overload Ref.) Yet as Markus and I discussed, there > > are two clear use cases for when an XRI author/XRD publisher wants to > > instruct consuming applications to replace one ID with another: > > > > 1) Migration: a resource current identified with ID A and described by > > XRD A from authority A is still the same resource but should now be > > identified by ID B described in XRD B from authority B. This happens > > all the time in the Web today - for example a website migrates from > > one domain to another. Authority A needs to notify consuming > > applications to begin using ID B because authority A will not continue > > maintaining ID A and XRD A forever. > > > > 2) Merging: two previously independently identified resources A and B > > (such as two businesses) are being merged into one resource (the > > "surviving resource"). This is an even stronger version of the above > > because Authority A needs to notify consuming applications that they > > MUST begin using ID B because ID A is no longer legally valid, i.e., > > the target resource no longer exists. > > > > If the element names "MapToID" and "MapFromID" are not semantically > > clear enough about this instruction, we could use stronger names such > > as "ChangeToID" and "ChangeFromID". > > > > However unless we can come up with some other solution (I'm all ears), > > this is a straightforward way to solve these use cases that has very > > precise semantics. > > > > =Drummond > > > > ------------------------------------------------------------------------ > > > > *From:* Chasen, Les [mailto:les.chasen@neustar.biz] > > *Sent:* Monday, August 20, 2007 10:10 AM > > *To:* Markus Sabadello; Tan, William > > *Cc:* Drummond Reed; Gabe Wachob; Davis, Peter; William Barnhill; > > steven.churchill@xdi.org; XRI TC; Andy Dale > > *Subject:* RE: [xri] ED04 synonym proposal (was RE: [xri] CID changes > > in wd11) > > > > I agree ... we should only need equivId. > > > > Let me add, just to get it out there ... I am generally ok with adding > > this new tag but I fear that there are some nuances that will not get > > uncovered because we are out of time to really think about this from > > all angles. > > > > contact: =les <http://xri.net/=les> > > > > voice: =les/(+phone) <http://xri.net/=les/%28+phone%29> > > > > chat: =les/skype/chat <http://xri.net/=les/skype/chat> > > > > pibb me =les/+pibb <http://xri.net/=les/+pibb> > > > > ------------------------------------------------------------------------ > > > > *From:* markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] > > *On Behalf Of *Markus Sabadello > > *Sent:* Monday, August 20, 2007 11:37 AM > > *To:* Tan, William > > *Cc:* Chasen, Les; Drummond Reed; Gabe Wachob; Davis, Peter; William > > Barnhill; steven.churchill@xdi.org; XRI TC; Andy Dale > > *Subject:* Re: [xri] ED04 synonym proposal (was RE: [xri] CID changes > > in wd11) > > > > > > I see it the other way round.. I think MapFromID / MapToID is > > unnecessary, because you can do everything just with the EquivID. > > > > And why should it not be enforcable? You just look for a matching > > EquivID in the second XRD. > > > > Markus > > > > On 8/20/07, *Tan, William* <William.Tan@neustar.biz > > <mailto:William.Tan@neustar.biz>> wrote: > > > > I agree with Les. It seems to me that we have the following: > > > > Ref - resolution semantics only > > EquivID - equivalence/synonymity semantics only (non-enforceable) > > MapToID - equivalence/synonymity semantics enforceable by resolution > > MapFromID - used as an explicit permission granting in order to support > > MapToID. A MapFromID will not be acted upon by the resolution client if > > it was not trying to verify a MapToID. > > > > It seems to me that EquivID is almost redundant, if one could express > > weak synonymity using a MapToID without the corresponding MapFromID. > > > > =wil > > > > Chasen, Les wrote: > > > > > > I do like the separation from existing attributes better. I am not > > > sure I see a strong enough reason for there to be an equivId and > > > MapToId. The proposal equates mapToId to an http 301 permanent > > > redirect. I am not sure that is a valid parallel to draw. There is > > > nothing in the proposal that makes the XRD that contains the mapToId > > > to not be used as one normally is used. > > > > > > > > > > > > contact: =les <http://xri.net/=les> > > > > > > voice: =les/(+phone) < http://xri.net/=les/%28+phone%29> > > > > > > chat: =les/skype/chat <http://xri.net/=les/skype/chat> > > > > > > pibb me =les/+pibb < http://xri.net/=les/+pibb> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > -- > > > > > > *From:* markus.sabadello@gmail.com > > <mailto:markus.sabadello@gmail.com> [mailto:markus.sabadello@gmail.com > > <mailto:markus.sabadello@gmail.com>] > > > *On Behalf Of *Markus Sabadello > > > *Sent:* Saturday, August 18, 2007 4:27 PM > > > *To:* Drummond Reed > > > *Cc:* Gabe Wachob; Davis, Peter; Chasen, Les; William Barnhill; > > > steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>; XRI TC; > > Andy Dale > > > *Subject:* Re: [xri] ED04 synonym proposal (was RE: [xri] CID changes > > > in wd11) > > > > > > > > > > > > > > > Having missed most of the TC call, I don't know what other peoples' > > > opinions are, but here's mine: > > > I like the EquivID, because it's easy to understand, has only one > > > meaning, and because it's symmetrical. The separation of "resolution > > > equivalence" (Ref) and "identification equivalence" (EquivID) sounds > > > very useful to me from a practical standpoint, although it would be > > > interesting to hear Steven's opinion about it. > > > > > > I would expect that EquivID be used much more often than Ref, or both > > > at the same time. > > > > > > I am not so sure about the MapToID / MapFromID.. What's the purpose of > > > that? I think I understand how it works, but what would be an example > > > for a use case in which the EquivID wouldn't be good enough? > > > > > > Markus > > > > > > On 8/16/07, *Drummond Reed* < drummond.reed@cordance.net > > <mailto:drummond.reed@cordance.net> > > > <mailto:drummond.reed@cordance.net > > <mailto:drummond.reed@cordance.net>>> wrote: > > > > > > Markus et al: > > > > > > > > > > > > I forgot to mention on today's call that it was Markus' message > > > yesterday, plus the talk Les and I had, that inspired the new synonym > > > proposal separating synonym semantics. Specifically Markus said: > > > > > > > > > > > > > Oh and by the way, what I never liked about Refs is that to me it > > > seems they do two different things at the same time. They say "This > > > identifier is a synonym" and "Follow it to find something". I > > > understand those two things are very closely linked, but we STILL have > > > no synonym element that simply says "This identifier is a synonym" > > > without any additional semantics like "follow it" or "it's canonical" > > > or "it's local". > > > > > > > > > > > > This is exactly what the new EquivID element will do, and why it is > > > decoupled from Ref in this proposal. Ref only means "follow this > > > identifier to discover another XRD describing this resource" and > > > nothing more. Markus went on to say: > > > > > > > > > > > > > Personally I would have chosen only a single element with optional > > > attributes called <Synonym follow="true" > > > canonical="false">@ootao*steven</Synonym>, instead of having four or > > > five different elements that have so similar semantics. > > > > > > > > > > > > Where I differ with Markus over this approach is that XML schema > > > semantics don't allow us to specify the zero-or-one cardinality > > > constraint that we want to have on CanonicalID and MapToID, so even > > > though it is more verbose, having separate elements lets us express > > > this constraint cleanly. > > > > > > > > > > > > In any case, this afternoon I spent time to reflect the feedback and > > > fully fleshed out the new synonym proposal at: > > > > > > > > > > > > http://wiki.oasis-open.org/xri/XriCd02/SynonymSemantics > > > > > > > > > > > > I urge everyone on this thread to review it and post any and all > > > feedback to the list so we can include the new writeup in ED04 next > week. > > > > > > > > > > > > BTW, in case you haven't read the minutes, we closed ALL OTHER ISSUES > > > on the telecon today, so if we have consensus on this, we are FULL > > > GREEN LIGHT to finish and vote on this spec by the end of the month!! > > > > > > > > > > > > =Drummond > > > > > > > > > > > > ---------------------------------------------------------------------- > -- > > > > > > *From:* markus.sabadello@gmail.com > > <mailto:markus.sabadello@gmail.com> <mailto:markus.sabadello@gmail.com > > <mailto:markus.sabadello@gmail.com>> > > > [mailto: markus.sabadello@gmail.com > <mailto:markus.sabadello@gmail.com> > > > <mailto:markus.sabadello@gmail.com > > <mailto:markus.sabadello@gmail.com>>] *On Behalf Of *Markus Sabadello > > > *Sent:* Thursday, August 16, 2007 10:58 AM > > > *To:* Gabe Wachob > > > *Cc:* Peter Davis; Drummond Reed; Les Chasen; William Barnhill; > > > steven.churchill@xdi.org <mailto:steven.churchill@xdi.org> > > <mailto:steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>>; > > XRI TC; > > > Andy Dale > > > *Subject:* Re: [xri] CID changes in wd11 > > > > > > > > > > > > > > > ... and I just ran out of quarters and dropped from the call :) > > > > > > Anyway I'm going to read through Drummond's new proposal.. What I > > > still understood on the call was that it includes a new element (equiv > > > id or something like that) that simply states identifier synonymity > > > without anything else, and I like that, since as I said in my other > > > mail the Ref element always seemed to me to do two different things at > > > the same time (identifier synonymity AND instructions to the resolver > > > to follow the Ref). > > > > > > Markus > > > > > > On 8/16/07, *Gabe Wachob* < gabe.wachob@amsoft.net > > <mailto:gabe.wachob@amsoft.net> > > > <mailto:gabe.wachob@amsoft.net <mailto:gabe.wachob@amsoft.net>>> > wrote: > > > > > > And I just learned from my office-mate and from Markus' email that > > > Skype is > > > down!!! > > > > > > Ol fashion cell call then ;-) > > > > > > > -----Original Message----- > > > > From: Gabe Wachob [mailto: gabe.wachob@amsoft.net > > <mailto:gabe.wachob@amsoft.net> > > > <mailto:gabe.wachob@amsoft.net <mailto:gabe.wachob@amsoft.net>>] > > > > Sent: Thursday, August 16, 2007 10:04 AM > > > > To: 'Peter Davis'; 'Drummond Reed'; 'Les Chasen'; > > > > markus.sabadello@xdi.org <mailto:markus.sabadello@xdi.org> > > <mailto:markus.sabadello@xdi.org <mailto:markus.sabadello@xdi.org>>; > > 'William > > > Barnhill' > > > > Cc: steven.churchill@xdi.org <mailto:steven.churchill@xdi.org> > > <mailto:steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>>; > 'XRI > > > TC'; 'Andy Dale' > > > > Subject: RE: [xri] CID changes in wd11 > > > > > > > > This gets back to the fundamental meta-architecture we're trying to > fit > > > > in: > > > > URIs. > > > > > > > > URIs are just identifiers and what real world things you associate > > with > > > > them > > > > is a social issue - not a technical one. > > > > > > > > "Proving" equality can only be a *definitional* task - we can say > > > that two > > > > things are "equal" because we define them to be equal. But we can > > never > > > > "prove" that they are equal without jumping out of the architectural > > > plane > > > > of the Internet... (well, I suppose for very narrow classes of > > > resources, > > > > like cryptoblobs, maybe we could do some "proofs", but that's a > > > degenerate > > > > case). > > > > > > > > I think Bill's questions, as stimulating as they were, are leading > > is off > > > > the important issue of what do we define, through syntax or > resolution > > > > *only*, to be equivalent. We don't really care about other > equivalence > > > > mechanisms - those are clearly out of scope. > > > > > > > > -gabe > > > > > > > > P.S. I'm skypeing in now. > > > > > > > > > -----Original Message----- > > > > > From: Peter Davis [mailto:peter.davis@neustar.biz > > <mailto:peter.davis@neustar.biz> > > > <mailto: peter.davis@neustar.biz <mailto:peter.davis@neustar.biz>>] > > > > > Sent: Thursday, August 16, 2007 5:51 AM > > > > > To: Drummond Reed; Les Chasen; markus.sabadello@xdi.org > > <mailto:markus.sabadello@xdi.org> > > > <mailto: markus.sabadello@xdi.org <mailto:markus.sabadello@xdi.org>>; > > William > > > > Barnhill > > > > > Cc: steven.churchill@xdi.org <mailto:steven.churchill@xdi.org> > > <mailto: steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>>; > XRI > > > TC; Andy Dale > > > > > Subject: Re: [xri] CID changes in wd11 > > > > > > > > > > In reality, of course, we've not proved a relationship at all.. > > Merely > > > > > hinted at a relationship between identifiers. Nothing in the XRDS > > > > > provides > > > > > a level of veracity which would support a proof. All we can really > > > say > > > > (I > > > > > think, unless I am missing a critical facet of this argument): > > > > > > > > > > "An anonymous party, who is authorized by a registries security > > > > > policy, > > > > > allowed a forward reference to another identifier" and similarly, > > > > > > > > > > "An anonymous party, who is authorized by a registries security > > > > > policy, > > > > > allowed a backwards reference to another identifier" > > > > > > > > > > Since we are not including the asserting parties security tokens > and > > > > > corresponding policies into the XRDS (and I do not think that we > > > > should). > > > > > This equivalence use case can be partially solved, but I think to > do > > > > real > > > > > proofs, we need much more (as yet unspecified) security material. > > > > > > > > > > I think it would be disingenuous to imply this proves anything > > > about the > > > > > relationship between two parties. > > > > > > > > > > =peterd > > > > > > > > > > > > > > > > > > > > On 8/16/2007 3:01 AM, "Drummond Reed" < > > drummond.reed@cordance.net <mailto:drummond.reed@cordance.net> > > > <mailto:drummond.reed@cordance.net > <mailto:drummond.reed@cordance.net>>> > > > > wrote: > > > > > > > > > > > Les, regarding your first sentence below ("They are all > different > > > > > resources > > > > > > with a declaration of synonimty via refs."), I think Marcus > makes a > > > > good > > > > > > point when he clarified that sometimes when we use "XRI > > > authority" we > > > > > are > > > > > > referring to the "resource represented by an XRI" and sometimes > > > we are > > > > > > referring to "the resource descriptor (XRD) to which the XRI > > > > resolves". > > > > > This > > > > > > leads to a lot of confusion. The XRI glossary (in XRI Syntax > > 2.0) is > > > > > clear > > > > > > that an eXtensible Resource Identifier identifies a *resource* > and > > > > that > > > > > the > > > > > > resource decriptor format to which an identifier resolves (an > > > > eXtensible > > > > > > Resource Descriptor) is a *descriptor of the resource*. So we > > always > > > > > have > > > > > > these three pieces involved: the identifier, the resource, and > the > > > > > resource > > > > > > descriptor (which I think of as standing "between" the > > identifer and > > > > the > > > > > > resource). I think it would be clearer in these discussions of > > > > synonyms > > > > > if > > > > > > we used these terms instead of "XRI authority" due to its > amibuity > > > > about > > > > > > whether you are referring to a resource or a resource > descriptor. > > > > > > > > > > > > > > > > > > > > > > > > For example, if you apply these terms to your answer to Bill's > > > > question, > > > > > > "They are all different resources with a declaration of > synonimty > > > via > > > > > > refs.", the answer doesn't make sense. Resources can never be > > > > > synonymous, > > > > > > only identifiers of resources can be synonymous. > > > > > > > > > > > > > > > > > > > > > > > > So, returning to Bill's questions: > > > > > > > > > > > > > > > > > > > > > > > > Fred: "@ootao*steven and =steven.churchill identify the same > > > > > > resource" > > > > > > Alice: "Prove it" > > > > > > Fred: ??? > > > > > > > > > > > > Fred: "@ootao*steven and =steven.churchill identify > > > different > > > > > > resources" > > > > > > Alice: "Prove it" > > > > > > Fred: ??? > > > > > > > > > > > > > > > > > > > > > > > > In essence, Bill's first question is asking, "Can you prove > > that two > > > > > > different identifiers from different identifier authorities > > identify > > > > the > > > > > > same resource?", and his second is asking, "Can you prove the > same > > > > thing > > > > > in > > > > > > the negative?" > > > > > > > > > > > > > > > > > > > > > > > > With the CanonicalID-can-be-polyarchical proposal in ED03, the > > answer > > > > is > > > > > > clearly "Yes" to the first question, and "No" to the second (in > > > fact I > > > > > don't > > > > > > think we've ever had an answer to Bill's second question, > because a > > > > lack > > > > > of > > > > > > synonyms does not necessary mean that two identifiers don't > > identify > > > > the > > > > > > same resource.) With the CanonicalID-must-be-hierachical > > > proposal, the > > > > > > answer to the first question is clearly "Not with a > > CanonicalID". As > > > > you > > > > > > point out, if we go the CanonicalID-must-be-hierachical > approach, > > > the > > > > > > question of whether XRI resolution infrastructure should be able > to > > > > > answer > > > > > > Bill's first question is one we need to decide as a TC is > > either in- > > > > > scope or > > > > > > out-of-scope. > > > > > > > > > > > > > > > > > > > > > > > > We'll take up on tomorrow's call. Talk to you then, > > > > > > > > > > > > > > > > > > > > > > > > =Drummond > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _____ > > > > > > > > > > > > From: Chasen, Les [mailto:les.chasen@neustar.biz > > <mailto:les.chasen@neustar.biz> > > > <mailto:les.chasen@neustar.biz <mailto:les.chasen@neustar.biz>>] > > > > > > Sent: Wednesday, August 15, 2007 2:59 PM > > > > > > To: markus.sabadello@xdi.org <mailto:markus.sabadello@xdi.org> > > <mailto:markus.sabadello@xdi.org <mailto:markus.sabadello@xdi.org>>; > > > barnhill_william@bah.com <mailto:barnhill_william@bah.com> <mailto: > > barnhill_william@bah.com <mailto:barnhill_william@bah.com>> > > > > > > Cc: drummond.reed@cordance.net > <mailto:drummond.reed@cordance.net> > > > <mailto:drummond.reed@cordance.net > > <mailto:drummond.reed@cordance.net>>; steven.churchill@xdi.org > > <mailto:steven.churchill@xdi.org> > > > <mailto:steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>>; > > > > > > xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org> > > <mailto:xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>>; > > > andy.dale@ootao.com <mailto:andy.dale@ootao.com> <mailto: > > andy.dale@ootao.com <mailto:andy.dale@ootao.com>> > > > > > > Subject: Re: [xri] CID changes in wd11 > > > > > > > > > > > > > > > > > > > > > > > > They are all different resources with a declaration of > > synonimty via > > > > > refs. > > > > > > I think it is open for debate whether we need to prove it. > > > > > > > > > > > > In the real world it is not necessarily proved when a claim such > as > > > > this > > > > > is > > > > > > made. The trust in the claim will depend on the context in > > which the > > > > > claim > > > > > > is being made. Under some circumstances you can obviously see a > > need > > > > to > > > > > > prove the relationship in many other you can see not needing > proof. > > > > It > > > > > is a > > > > > > question of level of risk. Similarily, I think this is the > > > > > responsibility of > > > > > > the client application/service as they are the only ones that > can > > > > decide > > > > > the > > > > > > proper level of authentication/approval of various claims. I > > can see > > > > > myself > > > > > > writing applications that choose to ignore synonyms because my > > > risk is > > > > > high > > > > > > and my trust levels are low. > > > > > > > > > > > > > > > > > > -------------------------- > > > > > > http://xri.net/=les.chasen <http://xri.net/=les.chasen > > <http://xri.net/=les.chasen>> > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: markus.sabadello@gmail.com > > <mailto:markus.sabadello@gmail.com> > > > <mailto: markus.sabadello@gmail.com > > <mailto:markus.sabadello@gmail.com>> < markus.sabadello@gmail.com > > <mailto:markus.sabadello@gmail.com> > > > <mailto: markus.sabadello@gmail.com > <mailto:markus.sabadello@gmail.com>>> > > > > > > To: Barnhill, William <barnhill_william@bah.com > > <mailto:barnhill_william@bah.com> > > > <mailto:barnhill_william@bah.com <mailto:barnhill_william@bah.com>>> > > > > > > Cc: Drummond Reed < drummond.reed@cordance.net > > <mailto:drummond.reed@cordance.net> > > > <mailto:drummond.reed@cordance.net > > <mailto:drummond.reed@cordance.net>>>; Steven Churchill > > > > > > <steven.churchill@xdi.org <mailto:steven.churchill@xdi.org> > > <mailto:steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>>>; > > > Chasen, Les; xri@lists.oasis-open.org > > <mailto:xri@lists.oasis-open.org> <mailto:xri@lists.oasis-open.org > > <mailto:xri@lists.oasis-open.org>> > > > > > > < xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org> > > <mailto:xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>>>; > > > Andy Dale <andy.dale@ootao.com <mailto:andy.dale@ootao.com> <mailto: > > andy.dale@ootao.com <mailto:andy.dale@ootao.com>>> > > > > > > Sent: Wed Aug 15 17:42:26 2007 > > > > > > Subject: Re: [xri] CID changes in wd11 > > > > > > > > > > > > I think it would go about like this (no guarantees!!): > > > > > > > > > > > > For question 1: > > > > > > > > > > > > if (Fred == Drummond) { > > > > > > > > > > > > Fred: "Just resolve them and look at their XRDs. They have the > > same > > > > > > CanonicalID, therefore they identify the same resource. They > have > > > > > different > > > > > > GlobalIDs. At least one of them has either a Ref or BackRef". > > > > > > > > > > > > } else if (Fred == Steven || Fred == Les) { > > > > > > > > > > > > Fred: "Just resolve them. They have different CanonicalIDs. But > > > one > > > > of > > > > > > them has a Ref, therefore they identify the same resource." > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > For question 2: > > > > > > > > > > > > if (Fred == Drummond || Fred == Les || Fred == Steven) { > > > > > > > > > > > > Fred: "Just resolve them. If there is no synonym element in > either > > > > > XRD, > > > > > > they are different resources." > > > > > > > > > > > > } > > > > > > > > > > > > Markus > > > > > > > > > > > > > > > > > > On 8/15/07, Barnhill, William < barnhill_william@bah.com > > <mailto:barnhill_william@bah.com> > > > <mailto:barnhill_william@bah.com <mailto:barnhill_william@bah.com>>> > > wrote: > > > > > > > > > > > > Quick question if I can, supposing the following > > > conversations > > > > > what > > > > > > are > > > > > > Fred's responses? > > > > > > > > > > > > Fred: "@ootao*steven and =steven.churchill identify the same > > > > > > resource" > > > > > > Alice: "Prove it" > > > > > > Fred: ??? > > > > > > > > > > > > Fred: "@ootao*steven and = steven.churchill identify different > > > > > > resources" > > > > > > Alice: "Prove it" > > > > > > Fred: ??? > > > > > > > > > > > > This would help me greatly, though may be a rehashing for > > > many > > > > > of > > > > > > you, > > > > > > Bill > > > > > > > > > > > > -- > > > > > > William Barnhill Phone: (315) 491-6765 > > > > > > Associate Email: > > > > > barnhill_william@bah.com <mailto:barnhill_william@bah.com> > > <mailto:barnhill_william@bah.com <mailto:barnhill_william@bah.com>> > > > > > > <mailto:barnhill_william@bah.com > > <mailto:barnhill_william@bah.com> <mailto:barnhill_william@bah.com > > <mailto:barnhill_william@bah.com>>> > > > > > > Booz | Allen | Hamilton i-name: = Bill.Barnhill > > > > > > "Delivering results that endure" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > From: markus.sabadello@gmail.com > > <mailto:markus.sabadello@gmail.com> > > > <mailto:markus.sabadello@gmail.com > <mailto:markus.sabadello@gmail.com>> > > > > > <mailto:markus.sabadello@gmail.com > > <mailto:markus.sabadello@gmail.com> <mailto:markus.sabadello@gmail.com > > <mailto:markus.sabadello@gmail.com>>> > > > > > > [mailto: markus.sabadello@gmail.com > > <mailto:markus.sabadello@gmail.com> > > > <mailto:markus.sabadello@gmail.com > <mailto:markus.sabadello@gmail.com>> > > > > <mailto: markus.sabadello@gmail.com > > <mailto:markus.sabadello@gmail.com> <mailto:markus.sabadello@gmail.com > > <mailto:markus.sabadello@gmail.com>>> > > > > > ] On > > > > > > Behalf Of Markus Sabadello > > > > > > Sent: Wednesday, August 15, 2007 3:57 PM > > > > > > To: Drummond Reed > > > > > > Cc: Steven Churchill; Chasen, Les; > > > xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org> <mailto: > > xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>> > > > > > > <mailto: xri@lists.oasis-open.org <mailto:xri@lists.oasis- > open.org> > > > <mailto:xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>>> > > ; Andy Dale > > > > > > Subject: Re: [xri] CID changes in wd11 > > > > > > > > > > > > > > > > > > I read all this 3 times now.. I can't shake the feeling that > > > > > > everyone is > > > > > > saying almost the same thing and that the problem lies in > > > > > > terminology such > > > > > > as "XRD", "authority" and "resource". > > > > > > > > > > > > Here are a few simple statements: > > > > > > 1. "@ootao*steven and =steven.churchill identify the same > > > > > resource". > > > > > > 2. "@ootao*steven and = steven.churchill are different XRI > > > > > > authorities". > > > > > > 3. "The CanonicalID is the preferred and unique identifier > > > > > (primary > > > > > > key) of > > > > > > a real-world resource." > > > > > > 4. "The CanonicalID is the preferred and unique identifier > > > > > (primary > > > > > > key) of > > > > > > an XRI authority." > > > > > > > > > > > > I think we all agree on (1). Those are two i-names > > > registered > > > > by > > > > > and > > > > > > identifying our friend Steven Churchill (the resource). > > > > > > > > > > > > I think we also all agree on (2), although I am not > > > completely > > > > > sure > > > > > > about > > > > > > that. Let me know if you disagree here. My understanding is > > > > that > > > > > > every XRI > > > > > > (except LOCAL synonyms) has an "authority" of its own. Local > > > > > > synonyms share > > > > > > the same authority, but "polyarchical" synonyms have > > > different > > > > > > authorities. > > > > > > Independent of that, when you resolve an XRI, you could of > > > > > course > > > > > > get > > > > > > different authorities (due to ref processing). > > > Technically (in > > > > > the > > > > > > GRS and > > > > > > the OpenXRI server), there is a 1:1 relationship between an > > > > > > authority and an > > > > > > XRD. > > > > > > > > > > > > Regarding (3) and (4), I think this is where the differences > > > > > lie. > > > > > > > > > > > > If you support (3), which I suspect Drummond does, then you > > > > > would > > > > > > use the > > > > > > same CanonicalID for all your i-names. I got ONE i-number > > > > which > > > > > > identifies > > > > > > ME, and I am supposed to use it as a CanonicalID for all i- > > > > names > > > > > I > > > > > > have > > > > > > (=markus, @id*markus, =peacekeeper, etc.). Those would all > > > > have > > > > > the > > > > > > same > > > > > > CanonicalID. I am able to establish a notion of > > > synonymity of > > > > > > identifiers > > > > > > BEFORE I do service endpoint selection! > > > > > > > > > > > > If you like (4) better (Les? Steven?), then the CanonicalID > > > > > > identifies an > > > > > > XRI authority instead of a real-world resource. I just > > > > resolved > > > > > > @ootao*steven and =steven.churchill , and they have different > > > > > > CanonicalIDs. > > > > > > But there is a Ref, which tells me they are synonyms. Like in > > > > > (3) I > > > > > > also > > > > > > have a notion of synonymity of identifiers before I do > > > service > > > > > > endpoint > > > > > > selection, but the CanonicalIDs of the identifiers are > > > > > different. > > > > > > Which is > > > > > > not a problem, since during resolution with ref processing > > > > > (OpenID > > > > > > for > > > > > > example), I get the same CanonicalID for both identifiers. > > > > > > > > > > > > ----> I think all this comes down to what's the relationship > > > > > between > > > > > > the > > > > > > terms "real-world resource" and "XRI authority", and which of > > > > > them > > > > > > should be > > > > > > identified by the CanonicalID. > > > > > > > > > > > > I have a question for Les (I'm not trying to make a point > > > with > > > > > that > > > > > > question, I really want to know): What happens when my i-name > > > > > > =markus > > > > > > expires (because I forget to pay for it) and then my evil > > > > > neighbour > > > > > > registers it? Will it get a new i-number? I hope so!!! > > > > Otherwise > > > > > he > > > > > > will be > > > > > > able to access all the OpenID relying parties I ever used, > > > > > right? > > > > > > Therefore, > > > > > > "The CanonicalID of the authority =markus changed", no? > > > Which > > > > is > > > > > a > > > > > > good > > > > > > thing, since it now refers to a different resource (my > > > > > neighbour), > > > > > > no? Or > > > > > > would you express this in different words? > > > > > > > > > > > > Oh and by the way, what I never liked about Refs is that > > > to me > > > > > it > > > > > > seems they > > > > > > do two different things at the same time. They say "This > > > > > identifier > > > > > > is a > > > > > > synonym" and "Follow it to find something". I understand > > > those > > > > > two > > > > > > things > > > > > > are very closely linked, but we STILL have no synonym > > > element > > > > > that > > > > > > simply > > > > > > says "This identifier is a synonym" without any additional > > > > > semantics > > > > > > like > > > > > > "follow it" or "it's canonical" or "it's local". > > > Personally I > > > > > would > > > > > > have > > > > > > chosen only a single element with optional attributes called > > > > > > <Synonym > > > > > > follow="true" canonical="false">@ootao*steven</Synonym>, > > > > instead > > > > > of > > > > > > having > > > > > > four or five different elements that have so similar > > > > semantics. > > > > > > > > > > > > I don't know if any of this helps or makes things even more > > > > > > complicated, > > > > > > after all I'm still new to this as compared to you XRI > > > > dinosaurs > > > > > :) > > > > > > Just > > > > > > trying to sum up my impressions of this ongoing discussion.. > > > > > > > > > > > > greetings, > > > > > > Markus > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/14/07, Drummond Reed < drummond.reed@cordance.net > > <mailto:drummond.reed@cordance.net> > > > <mailto:drummond.reed@cordance.net > > <mailto:drummond.reed@cordance.net>>> wrote: > > > > > > > > > > > > What I am hearing from Steve and Les essentially > > > boils > > > > > down > > > > > > to this: > > > > > > a CanonicalID value should not be allowed to be > > > polyarchical, > > > > > > because if it > > > > > > is polyarchical, it might need to change. If a CanonicalID > > > > value > > > > > > MUST be > > > > > > hierachical (which in had to be in order to be verified in > > > > WD11 > > > > > ED02 > > > > > > -- the > > > > > > draft I believe Les is proposing we revert CanonicalID to), > > > > then > > > > > > indeed > > > > > > verification is indeed simpler, as a CanonicalID MUST be > > > > issued > > > > > by > > > > > > the same > > > > > > authority authoritative for the XRD in which it appears. And > > > > if > > > > > an > > > > > > authority > > > > > > uses a persistent hierachical identifier as a > > > CanonicalID, it > > > > > never > > > > > > needs to > > > > > > change, because a hierachical identifier is always under the > > > > > control > > > > > > of the > > > > > > authority that issues it, whereas a polyarchical > > > identifier is > > > > > not. > > > > > > > > > > > > > > > > > > > > > > > > Lastly it follows that if a CanonicalID value MUST be > > > > > > hierarchical > > > > > > (which was the proposed definition of the GlobalID element), > > > > > then > > > > > > the > > > > > > primary rationale for GlobalID goes away (there may still > > > > > another > > > > > > secondary > > > > > > rationale for it, but that's another subject). > > > > > > > > > > > > > > > > > > > > > > > > However if we go this direction, it leaves us with a > > > > > > different > > > > > > problem: how can a real-world resource (such as a person) > > > > prove > > > > > that > > > > > > they > > > > > > are the same resource represented by two different XRDs with > > > > two > > > > > > different > > > > > > CanonicalIDs issued by two different parent authorities? > > > > > > > > > > > > > > > > > > > > > > > > We'd need to move the burden of this proof to our > > > > > > polyarchical > > > > > > synonyms, i.e., Refs and Backrefs. In this approach, XRD #1 > > > > from > > > > > > parent > > > > > > authority #1 could assert that it represented the same > > > > resource > > > > > as > > > > > > XRD #2 > > > > > > from parent authority #2 by including a Ref element whose > > > > value > > > > > was > > > > > > an > > > > > > identifier that resolved to XRD #2 (preferably the > > > CanonicalID > > > > > for > > > > > > XRD #2, > > > > > > but any absolute identifier for XRD #2 would work). > > > > > > > > > > > > > > > > > > > > > > > > To verify that this synonym assertion was true, > > > an XRI > > > > > > resolver > > > > > > would need to do the same thing proposed in ED03 section > > > 12.2, > > > > > i.e., > > > > > > confirm > > > > > > that a corresponding Backref element exists in XRD #2 > > > pointing > > > > > back > > > > > > to an > > > > > > identifier for XRD #2 (again, preferably the CanonicalID for > > > > XRD > > > > > > #1). I > > > > > > would argue that we should also allow a Ref element to be > > > used > > > > > for > > > > > > verification, i.e., if XRD #1 contains a Ref element > > > pointing > > > > to > > > > > XRD > > > > > > #2, and > > > > > > XRD #2 contains a Ref element pointing back to XRD #1, the > > > > > synonyms > > > > > > are > > > > > > verified in *both* directions. > > > > > > > > > > > > > > > > > > > > > > > > Since this "Ref verification" only works > > > > polyarchically > > > > > on > > > > > > Ref > > > > > > elements, it is a separate process that "CanonicalID > > > > > verification" > > > > > > which > > > > > > only works hierarchically on CanonicalID elements. This means > > > > > we'd > > > > > > need to > > > > > > add another XRI resolution parameter for requesting Ref > > > > > verification > > > > > > (I'd > > > > > > propose to call it "ref" but we already have the "refs" > > > > > parameter > > > > > > which is > > > > > > used to control whether refs are followed in service > > > endpoint > > > > > > selection, so > > > > > > another name would be better). > > > > > > > > > > > > > > > > > > > > > > > > The key thing we lose by going this direction is the > > > > > ability > > > > > > for the > > > > > > resource represented by an XRD to assert a polyarchical > > > > > identifier > > > > > > as its > > > > > > canonical identifier. Let me give an example. > > > > > > > > > > > > > > > > > > > > > > > > If I want to go into twelve different businesses > > > today > > > > > to > > > > > > establish > > > > > > an account and I want to prove to each of them that I > > > have the > > > > > same > > > > > > identity > > > > > > (for example, so they all give me good credit), I can > > > show all > > > > > > twelve of > > > > > > them the same credential with the same identifier (say > > > it's my > > > > > WA > > > > > > state > > > > > > driver's license #). If they believe this credential (which > > > > they > > > > > can > > > > > > verify), they can record this identifier in their databases > > > > and > > > > > they > > > > > > don't > > > > > > need to assign me their own local identifier (they may still > > > > > want to > > > > > > do > > > > > > that, but they don't HAVE to do that). This is the > > > > > > CanonicalID-can-be-polyarchical model proposed in ED03. > > > > > > > > > > > > > > > > > > > > > > > > By contrast, if none of the twelve businesses will > > > > > accept my > > > > > > my WA > > > > > > state driver's license # (or another external identifier) as > > > > > their > > > > > > identifier for me, they all MUST assign me their own local > > > > > > identifiers. To > > > > > > prove I am the same person, they can all put in their records > > > > > that I > > > > > > have a > > > > > > WA state driver's license #, but to do this they MUST > > > store at > > > > > least > > > > > > two > > > > > > identifiers: the one they assigned me, and my WA state > > > > driver's > > > > > > license #. > > > > > > This is the CanonicalID-must-be-hierarchical model that I > > > > > believe > > > > > > Les and > > > > > > Steve are proposing. > > > > > > > > > > > > > > > > > > > > > > > > Either model will work. They have contrasting > > > > > > advantages/disadvantages: > > > > > > > > > > > > > > > > > > > > > > > > CANONICALID-CAN-BE-POLYARCHICAL > > > > > > > > > > > > Advantages: > > > > > > > > > > > > - XRI authority can assert the same identifier > > > > > everywhere if > > > > > > it > > > > > > wants > > > > > > > > > > > > - Separate Ref verification process is not needed to > > > > > prove > > > > > > cross-domain identity > > > > > > > > > > > > - Consuming applications do not need to store more > > > > than > > > > > one > > > > > > identifier to support cross-domain identification > > > > > > > > > > > > Disadvantages: > > > > > > > > > > > > - CanonicalID can change > > > > > > > > > > > > - Verification of polyarchical CanonicalID value > > > > > involves an > > > > > > extra > > > > > > resolution step > > > > > > > > > > > > - GlobalID is needed for verification of polyarchical > > > > > > CanonicalIDs > > > > > > > > > > > > > > > > > > > > > > > > CANONICALID-MUST-BE-HIERACHICAL > > > > > > > > > > > > Advantages: > > > > > > > > > > > > - CanonicalID never needs to change > > > > > > > > > > > > - Verification of polyarchical CanonicalID values is > > > > > more > > > > > > efficient > > > > > > > > > > > > - GlobalID is not needed for verification > > > > > > > > > > > > Disadvantages: > > > > > > > > > > > > - XRI authority cannot assert the same identifier > > > > > everywhere > > > > > > if it > > > > > > wants > > > > > > > > > > > > - Separate Ref verification process is needed to > > > prove > > > > > > cross-domain > > > > > > identity > > > > > > > > > > > > - Consuming applications need to store more than one > > > > > > identifier to > > > > > > support cross-domain identification > > > > > > > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > =Drummond > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > From: Steven Churchill > > > > > > [mailto:steven.churchill@xdi.org > > <mailto:steven.churchill@xdi.org> <mailto: steven.churchill@xdi.org > > <mailto:steven.churchill@xdi.org>>] > > > > > > Sent: Tuesday, August 14, 2007 10:46 AM > > > > > > To: 'Chasen, Les'; 'Drummond Reed'; xri@lists.oasis- > > > > > open.org <http://open.org> <http://open.org> > > > > > > Cc: 'Andy Dale' > > > > > > > > > > > > Subject: RE: [xri] CID changes in wd11 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Les is taking the correct position in this debate. > > > > > > > > > > > > > > > > > > > > > > > > XRI Resolution has long supported an important > > > > identity > > > > > > model where > > > > > > an XRI authority's identity can be distinguished by its > > > > > CanonicalID. > > > > > > For > > > > > > example, if resolving an XRI produces a (verifiable) > > > > > CanonicalID, > > > > > > then, as > > > > > > an XRI resolution client, I can treat that XRI as a > > > synonym to > > > > a > > > > > > unique XRI > > > > > > authority-a unique record in the global database that Les > > > > > describes > > > > > > below. I > > > > > > like to think of this database as a hierarchical graph, but > > > > > these > > > > > > are really > > > > > > two legitimate ways of talking about the same identity model. > > > > > Each > > > > > > record in > > > > > > Les' database is just a node in my graph. In both cases, > > > these > > > > > > records/nodes > > > > > > can be thought of as "XRI authorities", and in both cases the > > > > > > absolute > > > > > > identity of this XRI authority-that characteristic which > > > > > > distinguishes it > > > > > > from all other XRI authorities-is its CanonicalID. > > > > > > > > > > > > > > > > > > > > > > > > Given this basic identity model, any resolution that > > > > > > produces a > > > > > > different verifiable CanonicalID simply addresses a different > > > > > > authority. > > > > > > This is by definition of the model. (It is the same way that > > > > in > > > > > a > > > > > > relational > > > > > > model, a different PK must address a different record.) Say I > > > > > > resolve a > > > > > > given XRI with a given set of input parameters and it > > > produces > > > > a > > > > > > verifiable > > > > > > CID. Now say I resolve it a minute later with the same set of > > > > > input > > > > > > parameters and it produces another verifiable CID. This > > > > scenario > > > > > can > > > > > > and > > > > > > does occur-especially in the face of Ref processing and > > > people > > > > > > provisioning > > > > > > their SEPs. For example, I can (right now) simply add an SEP > > > > to > > > > > > @ootao*steve's authority, and then the same resolution call a > > > > > minute > > > > > > later > > > > > > will return a different verifiable CID. So, indeed, a client > > > > can > > > > > get > > > > > > back a > > > > > > different XRI authority when making two consecutive > > > > (equivalent) > > > > > > resolution > > > > > > calls. But this is all fine and good because it is the way > > > > that > > > > > we > > > > > > designed > > > > > > Ref processing (a long, long time ago.) Given this behavior, > > > > the > > > > > > (CanonicalID) identity model is still sound, because, by > > > > > definition, > > > > > > the > > > > > > second resolution call simply returns a different XRI > > > > authority. > > > > > > > > > > > > > > > > > > > > > > > > As for the CanonicalID being optional, <CanonicalID> > > > > is > > > > > > simply an > > > > > > element in the XML metadata that one XRI authority uses to > > > > > describe > > > > > > another. > > > > > > The first authority can choose to use it or not. If it does > > > > not > > > > > use > > > > > > it, then > > > > > > a Resolution client obviously cannot use the element to > > > > > distinguish > > > > > > authorities. No harm no foul. As for immutability: if > > > > resolving > > > > > two > > > > > > XRIs > > > > > > produce to different verifiable CanonicalIDs then, by > > > > definition > > > > > of > > > > > > the > > > > > > model, they address different authorities-two different > > > > records > > > > > in > > > > > > Les' > > > > > > global database. > > > > > > > > > > > > > > > > > > > > > > > > I really respect and appreciate Les' effort to > > > protect > > > > > these > > > > > > fundamentals. The introduction of GlobalID is a giant step in > > > > > the > > > > > > wrong > > > > > > direction. It is an attempt to define a more complicated > > > > > identity > > > > > > model in > > > > > > the interest of solving a newly introduced use case. If that > > > > use > > > > > > case is > > > > > > indeed important (which I doubt) then it should be solved > > > > within > > > > > the > > > > > > existing model-not by trying to define a new one. > > > > > > > > > > > > > > > > > > > > > > > > ~ Steve > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PS: For the typical disclaimer, I need to point out > > > > that > > > > > XRI > > > > > > resolution supports many identity models, and resolution > > > > clients > > > > > may > > > > > > not > > > > > > care at all about using a CanonicalID in the fashion > > > described > > > > > > above. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > From: Chasen, Les [mailto: > > > > > les.chasen@neustar.biz <mailto:les.chasen@neustar.biz> > > <mailto:les.chasen@neustar.biz <mailto:les.chasen@neustar.biz>> > > > > > > <mailto: les.chasen@neustar.biz <mailto:les.chasen@neustar.biz> > > <mailto:les.chasen@neustar.biz <mailto:les.chasen@neustar.biz>>> ] > > > > > > Sent: Tuesday, August 14, 2007 12:16 AM > > > > > > To: Drummond Reed; xri@lists.oasis-open.org > > <mailto:xri@lists.oasis-open.org> > > > <mailto:xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>> > > > > > > <mailto: xri@lists.oasis-open.org > > <mailto:xri@lists.oasis-open.org> <mailto:xri@lists.oasis-open.org > > <mailto:xri@lists.oasis-open.org>>> > > > > > > Subject: RE: [xri] CID changes in wd11 > > > > > > > > > > > > > > > > > > > > > > > > Hi Drummond, > > > > > > > > > > > > > > > > > > > > > > > > Welcome back hope you had a nice vacation. > > > > > > > > > > > > > > > > > > > > > > > > Yes CID has always been optional and we cannot do > > > > > anymore > > > > > > than > > > > > > recommend that it be persistent. We have also never > > > actually > > > > > > spelled out > > > > > > that it cannot change. However, the implication has always > > > > been > > > > > > there that > > > > > > it is immutable. That is until the introduction of globalId > > > > and > > > > > the > > > > > > specification, for the first time, stating that CID is > > > > editable. > > > > > I > > > > > > think > > > > > > this is a huge architectural mistake given where we are > > > in the > > > > > life > > > > > > of XRI. > > > > > > We have a base of applications out there, at our insistence, > > > > > using > > > > > > CID as a > > > > > > persistent key. It is too late to change that now. > > > > > > > > > > > > > > > > > > > > > > > > I therefore propose that we take CID back to where it > > > > > was in > > > > > > WD10 > > > > > > and add extra text to codify that it should be left > > > immutable. > > > > > > Personally I > > > > > > would make it a MUST requirement but I recognize for the same > > > > > reason > > > > > > that it > > > > > > is an optional field and persistence is a recommendation we > > > > > cannot > > > > > > really > > > > > > require that it MUST be immutable. So a SHOULD be immutable > > > > is > > > > > > fine. > > > > > > > > > > > > > > > > > > > > > > > > contact: =les < http://xri.net/=les <http://xri.net/=les> > > > > > <http://xri.net/=les> > > > > > > > > > > > > > voice : =les/(+phone) > > > > < http://xri.net/=les/%28+phone%29> > > > > > > > > > > > > chat: =les/skype/chat < > > > http://xri.net/=les/skype/chat < http://xri.net/=les/skype/chat> > > > > > > <http://xri.net/=les/skype/chat> > > > > > > > > > > > > > pibb me =les/+pibb < http://xri.net/=les/+pibb> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > From: Drummond Reed > > > > > > [mailto: drummond.reed@cordance.net > > <mailto:drummond.reed@cordance.net> > > > <mailto:drummond.reed@cordance.net > <mailto:drummond.reed@cordance.net>>] > > > > > > Sent: Tuesday, August 14, 2007 1:37 AM > > > > > > To: Chasen, Les; xri@lists.oasis-open.org > > <mailto:xri@lists.oasis-open.org> > > > <mailto:xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>> > > > > > > <mailto:xri@lists.oasis-open.org > > <mailto:xri@lists.oasis-open.org> <mailto:xri@lists.oasis-open.org > > <mailto:xri@lists.oasis-open.org>> > > > > > > > Subject: RE: [xri] CID changes in wd11 > > > > > > > > > > > > > > > > > > > > > > > > Les, > > > > > > > > > > > > > > > > > > > > > > > > I have just returned from vacation and am still > > > > catching > > > > > up > > > > > > on email > > > > > > and the minutes of the meetings while I was gone. But > > > > regarding > > > > > your > > > > > > point > > > > > > about CIDs, here's some initial thoughts: > > > > > > > > > > > > > > > > > > > > > > > > 1) First, CanonicalID, like all synonym elements, > > > has > > > > > always > > > > > > been > > > > > > optional. There's no requirement than an XRD MUST assert an > > > > > > CanonicalID. > > > > > > It's RECOMMENDED, but for obvious reasons it's not > > > REQUIRED at > > > > > the > > > > > > spec > > > > > > level because some users of XRDS architecture don't need > > > > > > CanonicalIDs at > > > > > > all. > > > > > > > > > > > > > > > > > > > > > > > > 2) Second, there is no requirement that a CanonicalID > > > > > value > > > > > > be > > > > > > persistent. Again, it's RECOMMENDED, but not REQUIRED, as > > > some > > > > > > authorities > > > > > > don't either want or need persistent identifiers. > > > > > > > > > > > > > > > > > > > > > > > > So my first point is that as much as it would be > > > nice > > > > > for > > > > > > all XRDs > > > > > > to: a) have a CanonicalID value, and b) make it a persistent > > > > > > identifier that > > > > > > never changes, we have never (in WD10 or any earlier draft) > > > > > required > > > > > > for > > > > > > either to be true. An authority has always been able to > > > assert > > > > > any > > > > > > CanonicalID value they want, and change it anytime they > > > want. > > > > > The > > > > > > only > > > > > > change from WD10 to WD11 is that the cardinality of > > > > CanonicalID > > > > > went > > > > > > from > > > > > > zero-or-more to zero-or-one. > > > > > > > > > > > > > > > > > > > > > > > > Secondly, the main purpose of XRI synonym > > > architecture > > > > > is to > > > > > > model > > > > > > the real world in which a resource may have any number of > > > > > > identifiers > > > > > > assigned to it by any number of authorities. Each of these > > > > > > identifiers may > > > > > > be either reassignable or persistent. WD11 is the first > > > draft > > > > in > > > > > > which we > > > > > > have, in section 11 and specifically in Table 23 (page 60 of > > > > the > > > > > > PDF), fully > > > > > > captured the semantics necessary for an authority to assert > > > > the > > > > > set > > > > > > of > > > > > > identifiers it uses to identify a resource in such a manner > > > > that > > > > > > client > > > > > > applications have all the metadata they need to > > > understand how > > > > > to > > > > > > consume > > > > > > those identifiers to maintain a reference to the resource. > > > > > > > > > > > > > > > > > > > > > > > > Your specific concern is that client applications be > > > > > able to > > > > > > know > > > > > > which identifier they can use as a persistent global foreign > > > > key > > > > > for > > > > > > a > > > > > > resource. Table 23 explains that of the five synonym > > > elements > > > > > > available, > > > > > > only three fit the requirements of a global foreign key: > > > > > > CanonicalID, > > > > > > GlobalID, and Ref. LocalID and Backref do not meet the > > > > > requirements > > > > > > because: > > > > > > > > > > > > > > > > > > > > > > > > * LocalID is relative and not absolute. > > > > > > > > > > > > * Backref is an assertion that another authority is > > > > > > referencing the > > > > > > synonyms in the current XRD to identify the resource. > > > > > > > > > > > > > > > > > > > > > > > > However the other three - CanonicalID, GlobalID, and > > > > Ref > > > > > -- > > > > > > *all* > > > > > > can meet the requirements of global foreign keys for a > > > > resource. > > > > > > This begs > > > > > > the question: why have three XRD synonym elements that > > > can all > > > > > serve > > > > > > as > > > > > > global foreign keys? > > > > > > > > > > > > > > > > > > > > > > > > Table 23 provides the answer. GlobalID and Ref > > > cleanly > > > > > > separate > > > > > > global keys for a resource into two categories for trust > > > > > purposes: > > > > > > > > > > > > > > > > > > > > > > > > 1) Category #1 - GlobalIDs - are hierachical > > > > identifiers > > > > > > that are > > > > > > assigned by the authority for the XRD and thus can be > > > verified > > > > > > hierachically. > > > > > > > > > > > > > > > > > > > > > > > > 2) Category #2 - Refs - are polyarchical identifiers > > > > > that > > > > > > are > > > > > > assigned by authorities OTHER than the authority for the XRD > > > > and > > > > > > which thus > > > > > > must be verified polyarchically, i.e., by confirming the > > > > > > corresponding > > > > > > Backref. > > > > > > > > > > > > > > > > > > > > > > > > Given that between these two categories, we've > > > covered > > > > > 100% > > > > > > of the > > > > > > use cases (to the best of my knowledge), what then is the > > > > > purpose of > > > > > > the > > > > > > CanonicalID element? Why do we even need it? > > > > > > > > > > > > > > > > > > > > > > > > The answer is that, because an authority can assert > > > > any > > > > > > number of > > > > > > GlobalIDs or Refs for a resource (the use cases for asserting > > > > > > multiple > > > > > > GlobalIDs are pretty weak but the use cases for asserting > > > > > multiple > > > > > > Refs can > > > > > > be very strong), the additional value of the CanonicalID > > > > element > > > > > is > > > > > > that it > > > > > > gives XRD authorities a way to assert which ONE of these > > > > > multiple > > > > > > global > > > > > > foreign keys the authority RECOMMENDS client applications use > > > > to > > > > > > maintain a > > > > > > reference to the resource. > > > > > > > > > > > > > > > > > > > > > > > > So the net net is that the value(s) of the GlobalID > > > > > > (zero-or-more), > > > > > > Ref (zero-or-more), and the CanonicalID (zero-or-one) > > > elements > > > > > are > > > > > > all > > > > > > absolute identifiers that can serve as global foreign > > > keys for > > > > a > > > > > > resource. > > > > > > All the element tag tells you about these identifiers is: > > > > > > > > > > > > > > > > > > > > > > > > * Was it assigned by the authority for the XRD > > > > > (GlobalID)? > > > > > > > > > > > > * Was it NOT assigned by the authority for the XRD > > > > > (Ref)? > > > > > > > > > > > > * Of all the options, is it the recommended global > > > > > foreign > > > > > > key for > > > > > > the resource (CanonicalID)? > > > > > > > > > > > > > > > > > > > > > > > > This reveals the precise reason that the value of a > > > > > > CanonicalID > > > > > > element in an XRD could change over time: the parent > > > authority > > > > > > learns that > > > > > > the recommended global foreign key for a resource is > > > different > > > > > than > > > > > > the one > > > > > > the parent authority has heretofore been recommending. For > > > > > example, > > > > > > a parent > > > > > > authority could initially publish: > > > > > > > > > > > > > > > > > > > > > > > > <XRDS> > > > > > > > > > > > > <XRD> > > > > > > > > > > > > <Query>*example</Query> > > > > > > > > > > > > <GlobalID>=!1</GlobalID> > > > > > > > > > > > > > > > > > > <Ref> http://example.com/example/resource#1234</Ref> > > > > > > > > > > > > > > > > > > <Ref> https://example.com/example/resource#1234 > > <https://example.com/example/resource#1234> > > > > > > <https://example.com/example/resource#1234 > > > <https://example.com/example/resource#1234 > > <https://example.com/example/resource#1234>>> </Ref> > > > > > > > > > > > > > > > > > > > > > > > <CanonicalID>https://example.com/example/resource#1234 > > <https://example.com/example/resource#1234></CanonicalID> > > > > > > > > > > > > </XRD> > > > > > > > > > > > > </XRDS> > > > > > > > > > > > > > > > > > > > > > > > > But the resource identified by these three synonyms > > > > may > > > > > lose > > > > > > control > > > > > > over the domain name " example.com <http://example.com> > > <http://example.com> < > > > http://example.com> ". In > > > > > this > > > > > > case, even though > > > > > > https://example.com/example/resource#1234 > > > > > > < https://example.com/example/resource#1234 > > <https://example.com/example/resource#1234>> is a persistent > > > > identifier > > > > > (see > > > > > > below), the authority may decide that at that point it is > > > > better > > > > > to > > > > > > recommend a different persistent identifier as the > > > > CanonicalID. > > > > > Thus > > > > > > the XRD > > > > > > could change to: > > > > > > > > > > > > > > > > > > > > > > > > <XRDS> > > > > > > > > > > > > <XRD> > > > > > > > > > > > > <Query>*example</Query> > > > > > > > > > > > > <GlobalID>=!1</GlobalID> > > > > > > > > > > > > > > > > > > <Ref> http://example.com/example/resource#1234</Ref> > > > > > > > > > > > > > > > > > > <Ref> https://example.com/example/resource#1234 > > <https://example.com/example/resource#1234> > > > <https://example.com/example/resource#1234> > > > > > > <https://example.com/example/resource#1234 > > <https://example.com/example/resource#1234>> </Ref> > > > > > > > > > > > > > > > <CanonicalID>=!1</CanonicalID> > > > > > > > > > > > > </XRD> > > > > > > > > > > > > </XRDS> > > > > > > > > > > > > > > > > > > > > > > > > Note that the identifier " > > > > > > https://example.com/example/resource#1234" > > > > > > did NOT go away as a persistent global foreign key for the > > > > > resource. > > > > > > It's > > > > > > still there as a Ref, just as it was in the first > > > example. The > > > > > only > > > > > > change > > > > > > is that the CanonicalID now points to a different global > > > > foreign > > > > > key > > > > > > as the > > > > > > preferred one. > > > > > > > > > > > > > > > > > > > > > > > > Again note that NONE of the XRI synonym elements has > > > > the > > > > > > semantics > > > > > > that the identifier value MUST be persistent (not in WD11, > > > > WD10, > > > > > or > > > > > > any > > > > > > earlier draft). The way for a consuming application to tell > > > > > whether > > > > > > the > > > > > > identifier is asserted as persistent is to check for either > > > > XRI > > > > > > persistence > > > > > > semantics (! syntax for i-numbers) or URI persistence > > > > semantics > > > > > > (urn: or > > > > > > other persistent URI schemes). > > > > > > > > > > > > > > > > > > > > > > > > *********** > > > > > > > > > > > > I hope this helps. Clearly this issue is deep enough > > > > > that it > > > > > > can > > > > > > benefit more from direct phone or f2f discussion than from > > > > > email. I > > > > > > nominate > > > > > > it for the agenda for this week's TC call, but in the > > > meantime > > > > > feel > > > > > > free to > > > > > > call me if you want to discuss further. > > > > > > > > > > > > > > > > > > > > > > > > =Drummond > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > From: Chasen, Les > > > > > [mailto: les.chasen@neustar.biz <mailto:les.chasen@neustar.biz> > > <mailto:les.chasen@neustar.biz <mailto:les.chasen@neustar.biz>>] > > > > > > Sent: Monday, August 13, 2007 3:16 PM > > > > > > To: xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org> > > > <mailto:xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>> > > > > > > <mailto: xri@lists.oasis-open.org > > <mailto:xri@lists.oasis-open.org> <mailto:xri@lists.oasis-open.org > > <mailto:xri@lists.oasis-open.org>>> > > > > > > Subject: [xri] CID changes in wd11 > > > > > > > > > > > > > > > > > > > > > > > > Hi all - > > > > > > > > > > > > > > > > > > > > > > > > After reviewing the latest wd11 I have one major > > > > > concern. > > > > > > This > > > > > > version allows a CID to be changed after it is already set. > > > > I > > > > > > believe that > > > > > > this is a big mistake. The CID is the persistent identifier > > > > for > > > > > the > > > > > > queried > > > > > > XRD. We need to ensure that once an XRD has a CID that that > > > > CID > > > > > > identifies > > > > > > that XRD forever. > > > > > > > > > > > > > > > > > > > > > > > > I have always thought of the CID as a primary key to > > > > the > > > > > > global > > > > > > database we have created with XRI resolution. Client > > > > > applications > > > > > > have been > > > > > > and are being written that depend on the value of this > > > primary > > > > > key > > > > > > for the > > > > > > mapping of an identity described by an XRDS to their > > > internal > > > > > > account > > > > > > structure. If we allow this primary key to be changed we > > > have > > > > > > caused a > > > > > > major data integrity problem. > > > > > > > > > > > > > > > > > > > > > > > > I propose that the definition of CID not only revert > > > > > back to > > > > > > the > > > > > > WD10 definition but we also more strongly codify that a CID > > > > once > > > > > set > > > > > > should > > > > > > never be changed. > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > Les > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > contact: =les < http://xri.net/=les > > > > > <http://xri.net/=les> > > > > > > > > > > > > > voice : =les/(+phone) < > > > > > http://xri.net/=les/%28+phone%29> > > > > > > > > > > > > chat: =les/skype/chat < > > > http://xri.net/=les/skype/chat < http://xri.net/=les/skype/chat> > > > > > > <http://xri.net/=les/skype/chat> > > > > > > > > > > > > > pibb me =les/+pibb < http://xri.net/=les/+pibb> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =peterd ( http://xri.net/=peterd ) > > > > > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]