OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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


Subject: Re: [xri] 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]