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 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] 
> *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; 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>> 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>] *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>; 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>> 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>]
> > Sent: Thursday, August 16, 2007 10:04 AM
> > To: 'Peter Davis'; 'Drummond Reed'; 'Les Chasen';
> > markus.sabadello@xdi.org <mailto:markus.sabadello@xdi.org>; 'William 
> Barnhill'
> > Cc: 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>]
> > > Sent: Thursday, August 16, 2007 5:51 AM
> > > To: Drummond Reed; Les Chasen; markus.sabadello@xdi.org 
> <mailto:markus.sabadello@xdi.org>; William
> > Barnhill
> > > Cc: 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>>
> > 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>]
> > > > Sent: Wednesday, August 15, 2007 2:59 PM
> > > > To: markus.sabadello@xdi.org <mailto:markus.sabadello@xdi.org>; 
> barnhill_william@bah.com <mailto:barnhill_william@bah.com>
> > > > Cc: drummond.reed@cordance.net 
> <mailto:drummond.reed@cordance.net>; steven.churchill@xdi.org 
> <mailto:steven.churchill@xdi.org>;
> > > > xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>; 
> 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>
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: markus.sabadello@gmail.com 
> <mailto:markus.sabadello@gmail.com> < markus.sabadello@gmail.com 
> <mailto:markus.sabadello@gmail.com>>
> > > > To: Barnhill, William <barnhill_william@bah.com 
> <mailto:barnhill_william@bah.com>>
> > > > Cc: Drummond Reed < drummond.reed@cordance.net 
> <mailto:drummond.reed@cordance.net>>; Steven Churchill
> > > > <steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>>; 
> Chasen, Les; xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>
> > > > <xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>>; 
> Andy Dale <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>> 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>>
> > > >         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>>
> > > ] 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>> ; 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>> 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>]
> > > >                 Sent: Tuesday, August 14, 2007 10:46 AM
> > > >                 To: 'Chasen, Les'; 'Drummond Reed'; xri@lists.oasis-
> > > 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>> ]
> > > >                 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>>
> > > >                 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> >
> > > >
> > > >                 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>]
> > > >                 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> >
> > > >                 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>> </Ref>
> > > >
> > > >
> > > >
> > > <CanonicalID>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> ". In
> > > this
> > > > case, even though
> > > >         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> </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>]
> > > >                 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>>
> > > >                 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]