[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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</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”. In
this case, even though 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</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] 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 voice: =les/(+phone) chat: =les/skype/chat pibb me =les/+pibb |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]