[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)
See my comments inline: Drummond Reed wrote: > Let me explain why I'm comfortable with the "weaker" semantics for > MapToID/MapFromID that Wil proposes. > Great! > First, I agree with Les's point (two messages down) that MapToID/MapFromID > should, like EquivID, stay independent from resolution semantics. Their > purpose is strictly identification semantics. > > For this purpose, the key difference between EquivID and MapToID/MapFromID > is directionality. EquivID is non-directional and purely p2p. It doesn't > suggest to a consuming application anything more than "also known as". > Consuming apps can build or not build tables of EquivID mappings as needed, > but if they do build them, there is no directionality implied. > > By contrast, MapToID/MapFromID is strictly directional. As Wil puts it, they > enable express of "I would like to map to this other identifier" and "I > allow this other identifier to map to me". Again, consuming apps can build > or not build MapToID/MapFromID mapping tables as needed, but if they do > build them, they know exactly the directionality implied. As Wil notes, the > resolver can still verify the mapping even though the spec doesn't dictate > what "map" means. > > My feeling is that as long as non-directional and directional synonyms are > supported at the spec level, then specific identifier communities can set > policy around the uses these elements as they need. If we discover through > practice that additional semantics needed in the future, we can tackle that > when we get there. > I understand and agree that EquivID is p2p and non-directional, while MapToID/MapFromID are directional. I also understand that it would be Nice to be able to express an AKA relationship using a non-directional element. However, I'm not sure if the use case is a strong one. Generally, I would prefer to leave these to an extension (the X in XRDS) since it doesn't affect the core resolution behavior; my compiler has detected an "unreferenced local variable named EquivID". I also don't understand how you could use EquivID to express directional equivalence without MapToID/MapFromID. Unless, of course, you encode directionality into an attribute of EquivID, but that IMO is less preferable to having separate elements. =wil > =Drummond > > >> -----Original Message----- >> From: Chasen, Les [mailto:les.chasen@neustar.biz] >> Sent: Monday, August 20, 2007 3:52 PM >> To: Tan, William >> 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 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]