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" <> 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:]
> Sent: Wednesday, August 15, 2007 2:59 PM
> To: ;
> Cc: ; ;
> ;
> 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
>
>
> ----- Original Message -----
> From: <>
> To: Barnhill, William <>
> Cc: Drummond Reed <>; Steven Churchill
> <>; Chasen, Les;
> <>; Andy Dale <>
> 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 <> 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:
> <mailto:>
> Booz | Allen | Hamilton i-name: = Bill.Barnhill
> "Delivering results that endure"
>
>
>
>
>
> ________________________________
>
> From: <mailto:>
> [mailto: <mailto:> ] On
> Behalf Of Markus Sabadello
> Sent: Wednesday, August 15, 2007 3:57 PM
> To: Drummond Reed
> Cc: Steven Churchill; Chasen, Les;
> <mailto:> ; 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 < > 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:]
> Sent: Tuesday, August 14, 2007 10:46 AM
> To: 'Chasen, Les'; 'Drummond Reed';
> 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:
> <mailto:> ]
> Sent: Tuesday, August 14, 2007 12:16 AM
> To: Drummond Reed;
> <mailto:>
> 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> >
>
> pibb me =les/+pibb <http://xri.net/=les/+pibb>
>
>
>
>
>
>
>
>
>
> ________________________________
>
> From: Drummond Reed
> [mailto:]
> Sent: Tuesday, August 14, 2007 1:37 AM
> To: Chasen, Les;
> <mailto:>
> 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> </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> ". 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> </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:]
> Sent: Monday, August 13, 2007 3:16 PM
> To:
> <mailto:>
> 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> >
>
> pibb me =les/+pibb < http://xri.net/=les/+pibb>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
=peterd ( http://xri.net/=peterd )
