[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 agree with this but the proposal seems to take it further.
contact: =les
sip: =les/(+phone)
chat: =les/skype/chat
> -----Original Message-----
> From: Tan, William
> Sent: Monday, August 20, 2007 6:47 PM
> To: Chasen, Les
> Cc: Drummond Reed; Markus Sabadello; Gabe Wachob; Davis, Peter;
William
> Barnhill; steven.churchill@xdi.org; XRI TC; Andy Dale
> Subject: Re: [xri] ED04 synonym proposal (was RE: [xri] CID changes in
> wd11)
>
> I would say that the resolution spec simply provide the capability of
> expressing "I would like to map to this other identifier" and "I allow
> this other identifier to map to me". It is then up to the client to
> define what the verb "map" means. Note that the resolver can still
> verify the mapping even though it doesn't dictate what "map" means.
>
> =wil
>
> Chasen, Les wrote:
> >
> > There is a big difference between doing some analysis and analysis
> > paralysis. We are trying to put this particular proposal to bed in a
> > matter of days. I am not against it just pointing it out.
> >
> > When a web site is migrated to another domain more is done then just
a
> > redirect. It seems strange to say that mapToId tells the consuming
> > application to replace his existing identifier with the identifier
> > pointed to by the mapToId when there is nothing in the resolution
spec
> > that says that the original XRD can no longer be used. If XRD A maps
> > to XRD B that tells the consuming application to replace the
> > identifier for A to B. However, all the services in A continue to
> > resolve normally. With this proposal, do we need to re-look at
service
> > selection? Yuck I hope not.
> >
> > contact: =les <http://xri.net/=les>
> >
> > voice: =les/(+phone) <http://xri.net/=les/%28+phone%29>
> >
> > chat: =les/skype/chat <http://xri.net/=les/skype/chat>
> >
> > pibb me =les/+pibb <http://xri.net/=les/+pibb>
> >
> >
------------------------------------------------------------------------
> >
> > *From:* Drummond Reed [mailto:drummond.reed@cordance.net]
> > *Sent:* Monday, August 20, 2007 4:07 PM
> > *To:* Chasen, Les; 'Markus Sabadello'; Tan, William
> > *Cc:* 'Gabe Wachob'; Davis, Peter; 'William Barnhill';
> > steven.churchill@xdi.org; 'XRI TC'; 'Andy Dale'
> > *Subject:* RE: [xri] ED04 synonym proposal (was RE: [xri] CID
changes
> > in wd11)
> >
> > First, metapoint: Les has a good point he says, "I fear that there
are
> > some nuances that will not get uncovered because we are out of time
to
> > really think about this from all angles". That's a problem anytime
we
> > introduce new XRD elements. It is only with experience that all
their
> > nuances can get discovered. However if that prevented us from adding
> > new elements, we'd be stuck in "analysis paralysis" and never do
> anything.
> >
> > The situation now is that, if we want to keep LocalID, CanonicalID,
> > and Ref all with their current semantics (and in fact tighten down
the
> > semantics on Ref), we still need a way to express equivalence
> > relationships.
> >
> > I just had a good talk with Markus discussing why I believe both
> > EquivID and MapToID/MapFromID are needed. As I think we all agree,
> > EquivID establishes pure peer-to-peer identification synonymity.
> > Markus points out that the priority element can be used to rank
> > EquivIDs so that a consuming application can even understand which
is
> > the preferred peer synonym.
> >
> > But EquivID has no semantics regarding replacing one ID with another
> > one (and I wouldn't want to overload it with such, for the same
reason
> > we don't want to overload Ref.) Yet as Markus and I discussed, there
> > are two clear use cases for when an XRI author/XRD publisher wants
to
> > instruct consuming applications to replace one ID with another:
> >
> > 1) Migration: a resource current identified with ID A and described
by
> > XRD A from authority A is still the same resource but should now be
> > identified by ID B described in XRD B from authority B. This happens
> > all the time in the Web today - for example a website migrates from
> > one domain to another. Authority A needs to notify consuming
> > applications to begin using ID B because authority A will not
continue
> > maintaining ID A and XRD A forever.
> >
> > 2) Merging: two previously independently identified resources A and
B
> > (such as two businesses) are being merged into one resource (the
> > "surviving resource"). This is an even stronger version of the above
> > because Authority A needs to notify consuming applications that they
> > MUST begin using ID B because ID A is no longer legally valid, i.e.,
> > the target resource no longer exists.
> >
> > If the element names "MapToID" and "MapFromID" are not semantically
> > clear enough about this instruction, we could use stronger names
such
> > as "ChangeToID" and "ChangeFromID".
> >
> > However unless we can come up with some other solution (I'm all
ears),
> > this is a straightforward way to solve these use cases that has very
> > precise semantics.
> >
> > =Drummond
> >
> >
------------------------------------------------------------------------
> >
> > *From:* Chasen, Les [mailto:les.chasen@neustar.biz]
> > *Sent:* Monday, August 20, 2007 10:10 AM
> > *To:* Markus Sabadello; Tan, William
> > *Cc:* Drummond Reed; Gabe Wachob; Davis, Peter; William Barnhill;
> > steven.churchill@xdi.org; XRI TC; Andy Dale
> > *Subject:* RE: [xri] ED04 synonym proposal (was RE: [xri] CID
changes
> > in wd11)
> >
> > I agree ... we should only need equivId.
> >
> > Let me add, just to get it out there ... I am generally ok with
adding
> > this new tag but I fear that there are some nuances that will not
get
> > uncovered because we are out of time to really think about this from
> > all angles.
> >
> > contact: =les <http://xri.net/=les>
> >
> > voice: =les/(+phone) <http://xri.net/=les/%28+phone%29>
> >
> > chat: =les/skype/chat <http://xri.net/=les/skype/chat>
> >
> > pibb me =les/+pibb <http://xri.net/=les/+pibb>
> >
> >
------------------------------------------------------------------------
> >
> > *From:* markus.sabadello@gmail.com
[mailto:markus.sabadello@gmail.com]
> > *On Behalf Of *Markus Sabadello
> > *Sent:* Monday, August 20, 2007 11:37 AM
> > *To:* Tan, William
> > *Cc:* Chasen, Les; Drummond Reed; Gabe Wachob; Davis, Peter; William
> > Barnhill; steven.churchill@xdi.org; XRI TC; Andy Dale
> > *Subject:* Re: [xri] ED04 synonym proposal (was RE: [xri] CID
changes
> > in wd11)
> >
> >
> > I see it the other way round.. I think MapFromID / MapToID is
> > unnecessary, because you can do everything just with the EquivID.
> >
> > And why should it not be enforcable? You just look for a matching
> > EquivID in the second XRD.
> >
> > Markus
> >
> > On 8/20/07, *Tan, William* <William.Tan@neustar.biz
> > <mailto:William.Tan@neustar.biz>> wrote:
> >
> > I agree with Les. It seems to me that we have the following:
> >
> > Ref - resolution semantics only
> > EquivID - equivalence/synonymity semantics only (non-enforceable)
> > MapToID - equivalence/synonymity semantics enforceable by resolution
> > MapFromID - used as an explicit permission granting in order to
support
> > MapToID. A MapFromID will not be acted upon by the resolution client
if
> > it was not trying to verify a MapToID.
> >
> > It seems to me that EquivID is almost redundant, if one could
express
> > weak synonymity using a MapToID without the corresponding MapFromID.
> >
> > =wil
> >
> > Chasen, Les wrote:
> > >
> > > I do like the separation from existing attributes better. I am not
> > > sure I see a strong enough reason for there to be an equivId and
> > > MapToId. The proposal equates mapToId to an http 301 permanent
> > > redirect. I am not sure that is a valid parallel to draw. There is
> > > nothing in the proposal that makes the XRD that contains the
mapToId
> > > to not be used as one normally is used.
> > >
> > >
> > >
> > > contact: =les <http://xri.net/=les>
> > >
> > > voice: =les/(+phone) < http://xri.net/=les/%28+phone%29>
> > >
> > > chat: =les/skype/chat <http://xri.net/=les/skype/chat>
> > >
> > > pibb me =les/+pibb < http://xri.net/=les/+pibb>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
----------------------------------------------------------------------
> --
> > >
> > > *From:* markus.sabadello@gmail.com
> > <mailto:markus.sabadello@gmail.com>
[mailto:markus.sabadello@gmail.com
> > <mailto:markus.sabadello@gmail.com>]
> > > *On Behalf Of *Markus Sabadello
> > > *Sent:* Saturday, August 18, 2007 4:27 PM
> > > *To:* Drummond Reed
> > > *Cc:* Gabe Wachob; Davis, Peter; Chasen, Les; William Barnhill;
> > > steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>; XRI
TC;
> > Andy Dale
> > > *Subject:* Re: [xri] ED04 synonym proposal (was RE: [xri] CID
changes
> > > in wd11)
> > >
> > >
> > >
> > >
> > > Having missed most of the TC call, I don't know what other
peoples'
> > > opinions are, but here's mine:
> > > I like the EquivID, because it's easy to understand, has only one
> > > meaning, and because it's symmetrical. The separation of
"resolution
> > > equivalence" (Ref) and "identification equivalence" (EquivID)
sounds
> > > very useful to me from a practical standpoint, although it would
be
> > > interesting to hear Steven's opinion about it.
> > >
> > > I would expect that EquivID be used much more often than Ref, or
both
> > > at the same time.
> > >
> > > I am not so sure about the MapToID / MapFromID.. What's the
purpose of
> > > that? I think I understand how it works, but what would be an
example
> > > for a use case in which the EquivID wouldn't be good enough?
> > >
> > > Markus
> > >
> > > On 8/16/07, *Drummond Reed* < drummond.reed@cordance.net
> > <mailto:drummond.reed@cordance.net>
> > > <mailto:drummond.reed@cordance.net
> > <mailto:drummond.reed@cordance.net>>> wrote:
> > >
> > > Markus et al:
> > >
> > >
> > >
> > > I forgot to mention on today's call that it was Markus' message
> > > yesterday, plus the talk Les and I had, that inspired the new
synonym
> > > proposal separating synonym semantics. Specifically Markus said:
> > >
> > >
> > >
> > > > Oh and by the way, what I never liked about Refs is that to me
it
> > > seems they do two different things at the same time. They say
"This
> > > identifier is a synonym" and "Follow it to find something". I
> > > understand those two things are very closely linked, but we STILL
have
> > > no synonym element that simply says "This identifier is a synonym"
> > > without any additional semantics like "follow it" or "it's
canonical"
> > > or "it's local".
> > >
> > >
> > >
> > > This is exactly what the new EquivID element will do, and why it
is
> > > decoupled from Ref in this proposal. Ref only means "follow this
> > > identifier to discover another XRD describing this resource" and
> > > nothing more. Markus went on to say:
> > >
> > >
> > >
> > > > Personally I would have chosen only a single element with
optional
> > > attributes called <Synonym follow="true"
> > > canonical="false">@ootao*steven</Synonym>, instead of having four
or
> > > five different elements that have so similar semantics.
> > >
> > >
> > >
> > > Where I differ with Markus over this approach is that XML schema
> > > semantics don't allow us to specify the zero-or-one cardinality
> > > constraint that we want to have on CanonicalID and MapToID, so
even
> > > though it is more verbose, having separate elements lets us
express
> > > this constraint cleanly.
> > >
> > >
> > >
> > > In any case, this afternoon I spent time to reflect the feedback
and
> > > fully fleshed out the new synonym proposal at:
> > >
> > >
> > >
> > > http://wiki.oasis-open.org/xri/XriCd02/SynonymSemantics
> > >
> > >
> > >
> > > I urge everyone on this thread to review it and post any and all
> > > feedback to the list so we can include the new writeup in ED04
next
> week.
> > >
> > >
> > >
> > > BTW, in case you haven't read the minutes, we closed ALL OTHER
ISSUES
> > > on the telecon today, so if we have consensus on this, we are FULL
> > > GREEN LIGHT to finish and vote on this spec by the end of the
month!!
> > >
> > >
> > >
> > > =Drummond
> > >
> > >
> > >
> > >
----------------------------------------------------------------------
> --
> > >
> > > *From:* markus.sabadello@gmail.com
> > <mailto:markus.sabadello@gmail.com>
<mailto:markus.sabadello@gmail.com
> > <mailto:markus.sabadello@gmail.com>>
> > > [mailto: markus.sabadello@gmail.com
> <mailto:markus.sabadello@gmail.com>
> > > <mailto:markus.sabadello@gmail.com
> > <mailto:markus.sabadello@gmail.com>>] *On Behalf Of *Markus
Sabadello
> > > *Sent:* Thursday, August 16, 2007 10:58 AM
> > > *To:* Gabe Wachob
> > > *Cc:* Peter Davis; Drummond Reed; Les Chasen; William Barnhill;
> > > steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>
> > <mailto:steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>>;
> > XRI TC;
> > > Andy Dale
> > > *Subject:* Re: [xri] CID changes in wd11
> > >
> > >
> > >
> > >
> > > ... and I just ran out of quarters and dropped from the call :)
> > >
> > > Anyway I'm going to read through Drummond's new proposal.. What I
> > > still understood on the call was that it includes a new element
(equiv
> > > id or something like that) that simply states identifier
synonymity
> > > without anything else, and I like that, since as I said in my
other
> > > mail the Ref element always seemed to me to do two different
things at
> > > the same time (identifier synonymity AND instructions to the
resolver
> > > to follow the Ref).
> > >
> > > Markus
> > >
> > > On 8/16/07, *Gabe Wachob* < gabe.wachob@amsoft.net
> > <mailto:gabe.wachob@amsoft.net>
> > > <mailto:gabe.wachob@amsoft.net <mailto:gabe.wachob@amsoft.net>>>
> wrote:
> > >
> > > And I just learned from my office-mate and from Markus' email that
> > > Skype is
> > > down!!!
> > >
> > > Ol fashion cell call then ;-)
> > >
> > > > -----Original Message-----
> > > > From: Gabe Wachob [mailto: gabe.wachob@amsoft.net
> > <mailto:gabe.wachob@amsoft.net>
> > > <mailto:gabe.wachob@amsoft.net <mailto:gabe.wachob@amsoft.net>>]
> > > > Sent: Thursday, August 16, 2007 10:04 AM
> > > > To: 'Peter Davis'; 'Drummond Reed'; 'Les Chasen';
> > > > markus.sabadello@xdi.org <mailto:markus.sabadello@xdi.org>
> > <mailto:markus.sabadello@xdi.org <mailto:markus.sabadello@xdi.org>>;
> > 'William
> > > Barnhill'
> > > > Cc: steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>
> > <mailto:steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>>;
> 'XRI
> > > TC'; 'Andy Dale'
> > > > Subject: RE: [xri] CID changes in wd11
> > > >
> > > > This gets back to the fundamental meta-architecture we're trying
to
> fit
> > > > in:
> > > > URIs.
> > > >
> > > > URIs are just identifiers and what real world things you
associate
> > with
> > > > them
> > > > is a social issue - not a technical one.
> > > >
> > > > "Proving" equality can only be a *definitional* task - we can
say
> > > that two
> > > > things are "equal" because we define them to be equal. But we
can
> > never
> > > > "prove" that they are equal without jumping out of the
architectural
> > > plane
> > > > of the Internet... (well, I suppose for very narrow classes of
> > > resources,
> > > > like cryptoblobs, maybe we could do some "proofs", but that's a
> > > degenerate
> > > > case).
> > > >
> > > > I think Bill's questions, as stimulating as they were, are
leading
> > is off
> > > > the important issue of what do we define, through syntax or
> resolution
> > > > *only*, to be equivalent. We don't really care about other
> equivalence
> > > > mechanisms - those are clearly out of scope.
> > > >
> > > > -gabe
> > > >
> > > > P.S. I'm skypeing in now.
> > > >
> > > > > -----Original Message-----
> > > > > From: Peter Davis [mailto:peter.davis@neustar.biz
> > <mailto:peter.davis@neustar.biz>
> > > <mailto: peter.davis@neustar.biz
<mailto:peter.davis@neustar.biz>>]
> > > > > Sent: Thursday, August 16, 2007 5:51 AM
> > > > > To: Drummond Reed; Les Chasen; markus.sabadello@xdi.org
> > <mailto:markus.sabadello@xdi.org>
> > > <mailto: markus.sabadello@xdi.org
<mailto:markus.sabadello@xdi.org>>;
> > William
> > > > Barnhill
> > > > > Cc: steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>
> > <mailto: steven.churchill@xdi.org
<mailto:steven.churchill@xdi.org>>;
> XRI
> > > TC; Andy Dale
> > > > > Subject: Re: [xri] CID changes in wd11
> > > > >
> > > > > In reality, of course, we've not proved a relationship at
all..
> > Merely
> > > > > hinted at a relationship between identifiers. Nothing in the
XRDS
> > > > > provides
> > > > > a level of veracity which would support a proof. All we can
really
> > > say
> > > > (I
> > > > > think, unless I am missing a critical facet of this argument):
> > > > >
> > > > > "An anonymous party, who is authorized by a registries
security
> > > > > policy,
> > > > > allowed a forward reference to another identifier" and
similarly,
> > > > >
> > > > > "An anonymous party, who is authorized by a registries
security
> > > > > policy,
> > > > > allowed a backwards reference to another identifier"
> > > > >
> > > > > Since we are not including the asserting parties security
tokens
> and
> > > > > corresponding policies into the XRDS (and I do not think that
we
> > > > should).
> > > > > This equivalence use case can be partially solved, but I think
to
> do
> > > > real
> > > > > proofs, we need much more (as yet unspecified) security
material.
> > > > >
> > > > > I think it would be disingenuous to imply this proves anything
> > > about the
> > > > > relationship between two parties.
> > > > >
> > > > > =peterd
> > > > >
> > > > >
> > > > >
> > > > > On 8/16/2007 3:01 AM, "Drummond Reed" <
> > drummond.reed@cordance.net <mailto:drummond.reed@cordance.net>
> > > <mailto:drummond.reed@cordance.net
> <mailto:drummond.reed@cordance.net>>>
> > > > wrote:
> > > > >
> > > > > > Les, regarding your first sentence below ("They are all
> different
> > > > > resources
> > > > > > with a declaration of synonimty via refs."), I think Marcus
> makes a
> > > > good
> > > > > > point when he clarified that sometimes when we use "XRI
> > > authority" we
> > > > > are
> > > > > > referring to the "resource represented by an XRI" and
sometimes
> > > we are
> > > > > > referring to "the resource descriptor (XRD) to which the XRI
> > > > resolves".
> > > > > This
> > > > > > leads to a lot of confusion. The XRI glossary (in XRI Syntax
> > 2.0) is
> > > > > clear
> > > > > > that an eXtensible Resource Identifier identifies a
*resource*
> and
> > > > that
> > > > > the
> > > > > > resource decriptor format to which an identifier resolves
(an
> > > > eXtensible
> > > > > > Resource Descriptor) is a *descriptor of the resource*. So
we
> > always
> > > > > have
> > > > > > these three pieces involved: the identifier, the resource,
and
> the
> > > > > resource
> > > > > > descriptor (which I think of as standing "between" the
> > identifer and
> > > > the
> > > > > > resource). I think it would be clearer in these discussions
of
> > > > synonyms
> > > > > if
> > > > > > we used these terms instead of "XRI authority" due to its
> amibuity
> > > > about
> > > > > > whether you are referring to a resource or a resource
> descriptor.
> > > > > >
> > > > > >
> > > > > >
> > > > > > For example, if you apply these terms to your answer to
Bill's
> > > > question,
> > > > > > "They are all different resources with a declaration of
> synonimty
> > > via
> > > > > > refs.", the answer doesn't make sense. Resources can never
be
> > > > > synonymous,
> > > > > > only identifiers of resources can be synonymous.
> > > > > >
> > > > > >
> > > > > >
> > > > > > So, returning to Bill's questions:
> > > > > >
> > > > > >
> > > > > >
> > > > > > Fred: "@ootao*steven and =steven.churchill identify the same
> > > > > > resource"
> > > > > > Alice: "Prove it"
> > > > > > Fred: ???
> > > > > >
> > > > > > Fred: "@ootao*steven and =steven.churchill identify
> > > different
> > > > > > resources"
> > > > > > Alice: "Prove it"
> > > > > > Fred: ???
> > > > > >
> > > > > >
> > > > > >
> > > > > > In essence, Bill's first question is asking, "Can you prove
> > that two
> > > > > > different identifiers from different identifier authorities
> > identify
> > > > the
> > > > > > same resource?", and his second is asking, "Can you prove
the
> same
> > > > thing
> > > > > in
> > > > > > the negative?"
> > > > > >
> > > > > >
> > > > > >
> > > > > > With the CanonicalID-can-be-polyarchical proposal in ED03,
the
> > answer
> > > > is
> > > > > > clearly "Yes" to the first question, and "No" to the second
(in
> > > fact I
> > > > > don't
> > > > > > think we've ever had an answer to Bill's second question,
> because a
> > > > lack
> > > > > of
> > > > > > synonyms does not necessary mean that two identifiers don't
> > identify
> > > > the
> > > > > > same resource.) With the CanonicalID-must-be-hierachical
> > > proposal, the
> > > > > > answer to the first question is clearly "Not with a
> > CanonicalID". As
> > > > you
> > > > > > point out, if we go the CanonicalID-must-be-hierachical
> approach,
> > > the
> > > > > > question of whether XRI resolution infrastructure should be
able
> to
> > > > > answer
> > > > > > Bill's first question is one we need to decide as a TC is
> > either in-
> > > > > scope or
> > > > > > out-of-scope.
> > > > > >
> > > > > >
> > > > > >
> > > > > > We'll take up on tomorrow's call. Talk to you then,
> > > > > >
> > > > > >
> > > > > >
> > > > > > =Drummond
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > _____
> > > > > >
> > > > > > From: Chasen, Les [mailto:les.chasen@neustar.biz
> > <mailto:les.chasen@neustar.biz>
> > > <mailto:les.chasen@neustar.biz <mailto:les.chasen@neustar.biz>>]
> > > > > > Sent: Wednesday, August 15, 2007 2:59 PM
> > > > > > To: markus.sabadello@xdi.org
<mailto:markus.sabadello@xdi.org>
> > <mailto:markus.sabadello@xdi.org <mailto:markus.sabadello@xdi.org>>;
> > > barnhill_william@bah.com <mailto:barnhill_william@bah.com>
<mailto:
> > barnhill_william@bah.com <mailto:barnhill_william@bah.com>>
> > > > > > Cc: drummond.reed@cordance.net
> <mailto:drummond.reed@cordance.net>
> > > <mailto:drummond.reed@cordance.net
> > <mailto:drummond.reed@cordance.net>>; steven.churchill@xdi.org
> > <mailto:steven.churchill@xdi.org>
> > > <mailto:steven.churchill@xdi.org
<mailto:steven.churchill@xdi.org>>;
> > > > > > xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>
> > <mailto:xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>>;
> > > andy.dale@ootao.com <mailto:andy.dale@ootao.com> <mailto:
> > andy.dale@ootao.com <mailto:andy.dale@ootao.com>>
> > > > > > Subject: Re: [xri] CID changes in wd11
> > > > > >
> > > > > >
> > > > > >
> > > > > > They are all different resources with a declaration of
> > synonimty via
> > > > > refs.
> > > > > > I think it is open for debate whether we need to prove it.
> > > > > >
> > > > > > In the real world it is not necessarily proved when a claim
such
> as
> > > > this
> > > > > is
> > > > > > made. The trust in the claim will depend on the context in
> > which the
> > > > > claim
> > > > > > is being made. Under some circumstances you can obviously
see a
> > need
> > > > to
> > > > > > prove the relationship in many other you can see not needing
> proof.
> > > > It
> > > > > is a
> > > > > > question of level of risk. Similarily, I think this is the
> > > > > responsibility of
> > > > > > the client application/service as they are the only ones
that
> can
> > > > decide
> > > > > the
> > > > > > proper level of authentication/approval of various claims. I
> > can see
> > > > > myself
> > > > > > writing applications that choose to ignore synonyms because
my
> > > risk is
> > > > > high
> > > > > > and my trust levels are low.
> > > > > >
> > > > > >
> > > > > > --------------------------
> > > > > > http://xri.net/=les.chasen <http://xri.net/=les.chasen
> > <http://xri.net/=les.chasen>>
> > > > > >
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: markus.sabadello@gmail.com
> > <mailto:markus.sabadello@gmail.com>
> > > <mailto: markus.sabadello@gmail.com
> > <mailto:markus.sabadello@gmail.com>> < markus.sabadello@gmail.com
> > <mailto:markus.sabadello@gmail.com>
> > > <mailto: markus.sabadello@gmail.com
> <mailto:markus.sabadello@gmail.com>>>
> > > > > > To: Barnhill, William <barnhill_william@bah.com
> > <mailto:barnhill_william@bah.com>
> > > <mailto:barnhill_william@bah.com
<mailto:barnhill_william@bah.com>>>
> > > > > > Cc: Drummond Reed < drummond.reed@cordance.net
> > <mailto:drummond.reed@cordance.net>
> > > <mailto:drummond.reed@cordance.net
> > <mailto:drummond.reed@cordance.net>>>; Steven Churchill
> > > > > > <steven.churchill@xdi.org <mailto:steven.churchill@xdi.org>
> > <mailto:steven.churchill@xdi.org
<mailto:steven.churchill@xdi.org>>>;
> > > Chasen, Les; xri@lists.oasis-open.org
> > <mailto:xri@lists.oasis-open.org> <mailto:xri@lists.oasis-open.org
> > <mailto:xri@lists.oasis-open.org>>
> > > > > > < xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>
> > <mailto:xri@lists.oasis-open.org
<mailto:xri@lists.oasis-open.org>>>;
> > > Andy Dale <andy.dale@ootao.com <mailto:andy.dale@ootao.com>
<mailto:
> > andy.dale@ootao.com <mailto:andy.dale@ootao.com>>>
> > > > > > Sent: Wed Aug 15 17:42:26 2007
> > > > > > Subject: Re: [xri] CID changes in wd11
> > > > > >
> > > > > > I think it would go about like this (no guarantees!!):
> > > > > >
> > > > > > For question 1:
> > > > > >
> > > > > > if (Fred == Drummond) {
> > > > > >
> > > > > > Fred: "Just resolve them and look at their XRDs. They have
the
> > same
> > > > > > CanonicalID, therefore they identify the same resource. They
> have
> > > > > different
> > > > > > GlobalIDs. At least one of them has either a Ref or
BackRef".
> > > > > >
> > > > > > } else if (Fred == Steven || Fred == Les) {
> > > > > >
> > > > > > Fred: "Just resolve them. They have different CanonicalIDs.
But
> > > one
> > > > of
> > > > > > them has a Ref, therefore they identify the same resource."
> > > > > >
> > > > > > }
> > > > > >
> > > > > >
> > > > > > For question 2:
> > > > > >
> > > > > > if (Fred == Drummond || Fred == Les || Fred == Steven) {
> > > > > >
> > > > > > Fred: "Just resolve them. If there is no synonym element in
> either
> > > > > XRD,
> > > > > > they are different resources."
> > > > > >
> > > > > > }
> > > > > >
> > > > > > Markus
> > > > > >
> > > > > >
> > > > > > On 8/15/07, Barnhill, William < barnhill_william@bah.com
> > <mailto:barnhill_william@bah.com>
> > > <mailto:barnhill_william@bah.com
<mailto:barnhill_william@bah.com>>>
> > wrote:
> > > > > >
> > > > > > Quick question if I can, supposing the following
> > > conversations
> > > > > what
> > > > > > are
> > > > > > Fred's responses?
> > > > > >
> > > > > > Fred: "@ootao*steven and =steven.churchill identify the same
> > > > > > resource"
> > > > > > Alice: "Prove it"
> > > > > > Fred: ???
> > > > > >
> > > > > > Fred: "@ootao*steven and = steven.churchill identify
different
> > > > > > resources"
> > > > > > Alice: "Prove it"
> > > > > > Fred: ???
> > > > > >
> > > > > > This would help me greatly, though may be a rehashing for
> > > many
> > > > > of
> > > > > > you,
> > > > > > Bill
> > > > > >
> > > > > > --
> > > > > > William Barnhill Phone: (315) 491-6765
> > > > > > Associate Email:
> > > > > barnhill_william@bah.com <mailto:barnhill_william@bah.com>
> > <mailto:barnhill_william@bah.com <mailto:barnhill_william@bah.com>>
> > > > > > <mailto:barnhill_william@bah.com
> > <mailto:barnhill_william@bah.com> <mailto:barnhill_william@bah.com
> > <mailto:barnhill_william@bah.com>>>
> > > > > > Booz | Allen | Hamilton i-name: = Bill.Barnhill
> > > > > > "Delivering results that endure"
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > >
> > > > > > From: markus.sabadello@gmail.com
> > <mailto:markus.sabadello@gmail.com>
> > > <mailto:markus.sabadello@gmail.com
> <mailto:markus.sabadello@gmail.com>>
> > > > > <mailto:markus.sabadello@gmail.com
> > <mailto:markus.sabadello@gmail.com>
<mailto:markus.sabadello@gmail.com
> > <mailto:markus.sabadello@gmail.com>>>
> > > > > > [mailto: markus.sabadello@gmail.com
> > <mailto:markus.sabadello@gmail.com>
> > > <mailto:markus.sabadello@gmail.com
> <mailto:markus.sabadello@gmail.com>>
> > > > <mailto: markus.sabadello@gmail.com
> > <mailto:markus.sabadello@gmail.com>
<mailto:markus.sabadello@gmail.com
> > <mailto:markus.sabadello@gmail.com>>>
> > > > > ] On
> > > > > > Behalf Of Markus Sabadello
> > > > > > Sent: Wednesday, August 15, 2007 3:57 PM
> > > > > > To: Drummond Reed
> > > > > > Cc: Steven Churchill; Chasen, Les;
> > > xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>
<mailto:
> > xri@lists.oasis-open.org <mailto:xri@lists.oasis-open.org>>
> > > > > > <mailto: xri@lists.oasis-open.org <mailto:xri@lists.oasis-
> open.org>
> > > <mailto:xri@lists.oasis-open.org
<mailto:xri@lists.oasis-open.org>>>
> > ; Andy Dale
> > > > > > Subject: Re: [xri] CID changes in wd11
> > > > > >
> > > > > >
> > > > > > I read all this 3 times now.. I can't shake the feeling that
> > > > > > everyone is
> > > > > > saying almost the same thing and that the problem lies in
> > > > > > terminology such
> > > > > > as "XRD", "authority" and "resource".
> > > > > >
> > > > > > Here are a few simple statements:
> > > > > > 1. "@ootao*steven and =steven.churchill identify the same
> > > > > resource".
> > > > > > 2. "@ootao*steven and = steven.churchill are different XRI
> > > > > > authorities".
> > > > > > 3. "The CanonicalID is the preferred and unique identifier
> > > > > (primary
> > > > > > key) of
> > > > > > a real-world resource."
> > > > > > 4. "The CanonicalID is the preferred and unique identifier
> > > > > (primary
> > > > > > key) of
> > > > > > an XRI authority."
> > > > > >
> > > > > > I think we all agree on (1). Those are two i-names
> > > registered
> > > > by
> > > > > and
> > > > > > identifying our friend Steven Churchill (the resource).
> > > > > >
> > > > > > I think we also all agree on (2), although I am not
> > > completely
> > > > > sure
> > > > > > about
> > > > > > that. Let me know if you disagree here. My understanding is
> > > > that
> > > > > > every XRI
> > > > > > (except LOCAL synonyms) has an "authority" of its own. Local
> > > > > > synonyms share
> > > > > > the same authority, but "polyarchical" synonyms have
> > > different
> > > > > > authorities.
> > > > > > Independent of that, when you resolve an XRI, you could of
> > > > > course
> > > > > > get
> > > > > > different authorities (due to ref processing).
> > > Technically (in
> > > > > the
> > > > > > GRS and
> > > > > > the OpenXRI server), there is a 1:1 relationship between an
> > > > > > authority and an
> > > > > > XRD.
> > > > > >
> > > > > > Regarding (3) and (4), I think this is where the differences
> > > > > lie.
> > > > > >
> > > > > > If you support (3), which I suspect Drummond does, then you
> > > > > would
> > > > > > use the
> > > > > > same CanonicalID for all your i-names. I got ONE i-number
> > > > which
> > > > > > identifies
> > > > > > ME, and I am supposed to use it as a CanonicalID for all i-
> > > > names
> > > > > I
> > > > > > have
> > > > > > (=markus, @id*markus, =peacekeeper, etc.). Those would all
> > > > have
> > > > > the
> > > > > > same
> > > > > > CanonicalID. I am able to establish a notion of
> > > synonymity of
> > > > > > identifiers
> > > > > > BEFORE I do service endpoint selection!
> > > > > >
> > > > > > If you like (4) better (Les? Steven?), then the CanonicalID
> > > > > > identifies an
> > > > > > XRI authority instead of a real-world resource. I just
> > > > resolved
> > > > > > @ootao*steven and =steven.churchill , and they have
different
> > > > > > CanonicalIDs.
> > > > > > But there is a Ref, which tells me they are synonyms. Like
in
> > > > > (3) I
> > > > > > also
> > > > > > have a notion of synonymity of identifiers before I do
> > > service
> > > > > > endpoint
> > > > > > selection, but the CanonicalIDs of the identifiers are
> > > > > different.
> > > > > > Which is
> > > > > > not a problem, since during resolution with ref processing
> > > > > (OpenID
> > > > > > for
> > > > > > example), I get the same CanonicalID for both identifiers.
> > > > > >
> > > > > > ----> I think all this comes down to what's the relationship
> > > > > between
> > > > > > the
> > > > > > terms "real-world resource" and "XRI authority", and which
of
> > > > > them
> > > > > > should be
> > > > > > identified by the CanonicalID.
> > > > > >
> > > > > > I have a question for Les (I'm not trying to make a point
> > > with
> > > > > that
> > > > > > question, I really want to know): What happens when my
i-name
> > > > > > =markus
> > > > > > expires (because I forget to pay for it) and then my evil
> > > > > neighbour
> > > > > > registers it? Will it get a new i-number? I hope so!!!
> > > > Otherwise
> > > > > he
> > > > > > will be
> > > > > > able to access all the OpenID relying parties I ever used,
> > > > > right?
> > > > > > Therefore,
> > > > > > "The CanonicalID of the authority =markus changed", no?
> > > Which
> > > > is
> > > > > a
> > > > > > good
> > > > > > thing, since it now refers to a different resource (my
> > > > > neighbour),
> > > > > > no? Or
> > > > > > would you express this in different words?
> > > > > >
> > > > > > Oh and by the way, what I never liked about Refs is that
> > > to me
> > > > > it
> > > > > > seems they
> > > > > > do two different things at the same time. They say "This
> > > > > identifier
> > > > > > is a
> > > > > > synonym" and "Follow it to find something". I understand
> > > those
> > > > > two
> > > > > > things
> > > > > > are very closely linked, but we STILL have no synonym
> > > element
> > > > > that
> > > > > > simply
> > > > > > says "This identifier is a synonym" without any additional
> > > > > semantics
> > > > > > like
> > > > > > "follow it" or "it's canonical" or "it's local".
> > > Personally I
> > > > > would
> > > > > > have
> > > > > > chosen only a single element with optional attributes called
> > > > > > <Synonym
> > > > > > follow="true" canonical="false">@ootao*steven</Synonym>,
> > > > instead
> > > > > of
> > > > > > having
> > > > > > four or five different elements that have so similar
> > > > semantics.
> > > > > >
> > > > > > I don't know if any of this helps or makes things even more
> > > > > > complicated,
> > > > > > after all I'm still new to this as compared to you XRI
> > > > dinosaurs
> > > > > :)
> > > > > > Just
> > > > > > trying to sum up my impressions of this ongoing discussion..
> > > > > >
> > > > > > greetings,
> > > > > > Markus
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 8/14/07, Drummond Reed < drummond.reed@cordance.net
> > <mailto:drummond.reed@cordance.net>
> > > <mailto:drummond.reed@cordance.net
> > <mailto:drummond.reed@cordance.net>>> wrote:
> > > > > >
> > > > > > What I am hearing from Steve and Les essentially
> > > boils
> > > > > down
> > > > > > to this:
> > > > > > a CanonicalID value should not be allowed to be
> > > polyarchical,
> > > > > > because if it
> > > > > > is polyarchical, it might need to change. If a CanonicalID
> > > > value
> > > > > > MUST be
> > > > > > hierachical (which in had to be in order to be verified in
> > > > WD11
> > > > > ED02
> > > > > > -- the
> > > > > > draft I believe Les is proposing we revert CanonicalID to),
> > > > then
> > > > > > indeed
> > > > > > verification is indeed simpler, as a CanonicalID MUST be
> > > > issued
> > > > > by
> > > > > > the same
> > > > > > authority authoritative for the XRD in which it appears. And
> > > > if
> > > > > an
> > > > > > authority
> > > > > > uses a persistent hierachical identifier as a
> > > CanonicalID, it
> > > > > never
> > > > > > needs to
> > > > > > change, because a hierachical identifier is always under the
> > > > > control
> > > > > > of the
> > > > > > authority that issues it, whereas a polyarchical
> > > identifier is
> > > > > not.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Lastly it follows that if a CanonicalID value MUST be
> > > > > > hierarchical
> > > > > > (which was the proposed definition of the GlobalID element),
> > > > > then
> > > > > > the
> > > > > > primary rationale for GlobalID goes away (there may still
> > > > > another
> > > > > > secondary
> > > > > > rationale for it, but that's another subject).
> > > > > >
> > > > > >
> > > > > >
> > > > > > However if we go this direction, it leaves us with a
> > > > > > different
> > > > > > problem: how can a real-world resource (such as a person)
> > > > prove
> > > > > that
> > > > > > they
> > > > > > are the same resource represented by two different XRDs with
> > > > two
> > > > > > different
> > > > > > CanonicalIDs issued by two different parent authorities?
> > > > > >
> > > > > >
> > > > > >
> > > > > > We'd need to move the burden of this proof to our
> > > > > > polyarchical
> > > > > > synonyms, i.e., Refs and Backrefs. In this approach, XRD #1
> > > > from
> > > > > > parent
> > > > > > authority #1 could assert that it represented the same
> > > > resource
> > > > > as
> > > > > > XRD #2
> > > > > > from parent authority #2 by including a Ref element whose
> > > > value
> > > > > was
> > > > > > an
> > > > > > identifier that resolved to XRD #2 (preferably the
> > > CanonicalID
> > > > > for
> > > > > > XRD #2,
> > > > > > but any absolute identifier for XRD #2 would work).
> > > > > >
> > > > > >
> > > > > >
> > > > > > To verify that this synonym assertion was true,
> > > an XRI
> > > > > > resolver
> > > > > > would need to do the same thing proposed in ED03 section
> > > 12.2,
> > > > > i.e.,
> > > > > > confirm
> > > > > > that a corresponding Backref element exists in XRD #2
> > > pointing
> > > > > back
> > > > > > to an
> > > > > > identifier for XRD #2 (again, preferably the CanonicalID for
> > > > XRD
> > > > > > #1). I
> > > > > > would argue that we should also allow a Ref element to be
> > > used
> > > > > for
> > > > > > verification, i.e., if XRD #1 contains a Ref element
> > > pointing
> > > > to
> > > > > XRD
> > > > > > #2, and
> > > > > > XRD #2 contains a Ref element pointing back to XRD #1, the
> > > > > synonyms
> > > > > > are
> > > > > > verified in *both* directions.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Since this "Ref verification" only works
> > > > polyarchically
> > > > > on
> > > > > > Ref
> > > > > > elements, it is a separate process that "CanonicalID
> > > > > verification"
> > > > > > which
> > > > > > only works hierarchically on CanonicalID elements. This
means
> > > > > we'd
> > > > > > need to
> > > > > > add another XRI resolution parameter for requesting Ref
> > > > > verification
> > > > > > (I'd
> > > > > > propose to call it "ref" but we already have the "refs"
> > > > > parameter
> > > > > > which is
> > > > > > used to control whether refs are followed in service
> > > endpoint
> > > > > > selection, so
> > > > > > another name would be better).
> > > > > >
> > > > > >
> > > > > >
> > > > > > The key thing we lose by going this direction is the
> > > > > ability
> > > > > > for the
> > > > > > resource represented by an XRD to assert a polyarchical
> > > > > identifier
> > > > > > as its
> > > > > > canonical identifier. Let me give an example.
> > > > > >
> > > > > >
> > > > > >
> > > > > > If I want to go into twelve different businesses
> > > today
> > > > > to
> > > > > > establish
> > > > > > an account and I want to prove to each of them that I
> > > have the
> > > > > same
> > > > > > identity
> > > > > > (for example, so they all give me good credit), I can
> > > show all
> > > > > > twelve of
> > > > > > them the same credential with the same identifier (say
> > > it's my
> > > > > WA
> > > > > > state
> > > > > > driver's license #). If they believe this credential (which
> > > > they
> > > > > can
> > > > > > verify), they can record this identifier in their databases
> > > > and
> > > > > they
> > > > > > don't
> > > > > > need to assign me their own local identifier (they may still
> > > > > want to
> > > > > > do
> > > > > > that, but they don't HAVE to do that). This is the
> > > > > > CanonicalID-can-be-polyarchical model proposed in ED03.
> > > > > >
> > > > > >
> > > > > >
> > > > > > By contrast, if none of the twelve businesses will
> > > > > accept my
> > > > > > my WA
> > > > > > state driver's license # (or another external identifier) as
> > > > > their
> > > > > > identifier for me, they all MUST assign me their own local
> > > > > > identifiers. To
> > > > > > prove I am the same person, they can all put in their
records
> > > > > that I
> > > > > > have a
> > > > > > WA state driver's license #, but to do this they MUST
> > > store at
> > > > > least
> > > > > > two
> > > > > > identifiers: the one they assigned me, and my WA state
> > > > driver's
> > > > > > license #.
> > > > > > This is the CanonicalID-must-be-hierarchical model that I
> > > > > believe
> > > > > > Les and
> > > > > > Steve are proposing.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Either model will work. They have contrasting
> > > > > > advantages/disadvantages:
> > > > > >
> > > > > >
> > > > > >
> > > > > > CANONICALID-CAN-BE-POLYARCHICAL
> > > > > >
> > > > > > Advantages:
> > > > > >
> > > > > > - XRI authority can assert the same identifier
> > > > > everywhere if
> > > > > > it
> > > > > > wants
> > > > > >
> > > > > > - Separate Ref verification process is not needed to
> > > > > prove
> > > > > > cross-domain identity
> > > > > >
> > > > > > - Consuming applications do not need to store more
> > > > than
> > > > > one
> > > > > > identifier to support cross-domain identification
> > > > > >
> > > > > > Disadvantages:
> > > > > >
> > > > > > - CanonicalID can change
> > > > > >
> > > > > > - Verification of polyarchical CanonicalID value
> > > > > involves an
> > > > > > extra
> > > > > > resolution step
> > > > > >
> > > > > > - GlobalID is needed for verification of polyarchical
> > > > > > CanonicalIDs
> > > > > >
> > > > > >
> > > > > >
> > > > > > CANONICALID-MUST-BE-HIERACHICAL
> > > > > >
> > > > > > Advantages:
> > > > > >
> > > > > > - CanonicalID never needs to change
> > > > > >
> > > > > > - Verification of polyarchical CanonicalID values is
> > > > > more
> > > > > > efficient
> > > > > >
> > > > > > - GlobalID is not needed for verification
> > > > > >
> > > > > > Disadvantages:
> > > > > >
> > > > > > - XRI authority cannot assert the same identifier
> > > > > everywhere
> > > > > > if it
> > > > > > wants
> > > > > >
> > > > > > - Separate Ref verification process is needed to
> > > prove
> > > > > > cross-domain
> > > > > > identity
> > > > > >
> > > > > > - Consuming applications need to store more than one
> > > > > > identifier to
> > > > > > support cross-domain identification
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > >
> > > > > >
> > > > > > =Drummond
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > >
> > > > > > From: Steven Churchill
> > > > > > [mailto:steven.churchill@xdi.org
> > <mailto:steven.churchill@xdi.org> <mailto: steven.churchill@xdi.org
> > <mailto:steven.churchill@xdi.org>>]
> > > > > > Sent: Tuesday, August 14, 2007 10:46 AM
> > > > > > To: 'Chasen, Les'; 'Drummond Reed'; xri@lists.oasis-
> > > > > open.org <http://open.org> <http://open.org>
> > > > > > Cc: 'Andy Dale'
> > > > > >
> > > > > > Subject: RE: [xri] CID changes in wd11
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Les is taking the correct position in this debate.
> > > > > >
> > > > > >
> > > > > >
> > > > > > XRI Resolution has long supported an important
> > > > identity
> > > > > > model where
> > > > > > an XRI authority's identity can be distinguished by its
> > > > > CanonicalID.
> > > > > > For
> > > > > > example, if resolving an XRI produces a (verifiable)
> > > > > CanonicalID,
> > > > > > then, as
> > > > > > an XRI resolution client, I can treat that XRI as a
> > > synonym to
> > > > a
> > > > > > unique XRI
> > > > > > authority-a unique record in the global database that Les
> > > > > describes
> > > > > > below. I
> > > > > > like to think of this database as a hierarchical graph, but
> > > > > these
> > > > > > are really
> > > > > > two legitimate ways of talking about the same identity
model.
> > > > > Each
> > > > > > record in
> > > > > > Les' database is just a node in my graph. In both cases,
> > > these
> > > > > > records/nodes
> > > > > > can be thought of as "XRI authorities", and in both cases
the
> > > > > > absolute
> > > > > > identity of this XRI authority-that characteristic which
> > > > > > distinguishes it
> > > > > > from all other XRI authorities-is its CanonicalID.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Given this basic identity model, any resolution that
> > > > > > produces a
> > > > > > different verifiable CanonicalID simply addresses a
different
> > > > > > authority.
> > > > > > This is by definition of the model. (It is the same way that
> > > > in
> > > > > a
> > > > > > relational
> > > > > > model, a different PK must address a different record.) Say
I
> > > > > > resolve a
> > > > > > given XRI with a given set of input parameters and it
> > > produces
> > > > a
> > > > > > verifiable
> > > > > > CID. Now say I resolve it a minute later with the same set
of
> > > > > input
> > > > > > parameters and it produces another verifiable CID. This
> > > > scenario
> > > > > can
> > > > > > and
> > > > > > does occur-especially in the face of Ref processing and
> > > people
> > > > > > provisioning
> > > > > > their SEPs. For example, I can (right now) simply add an SEP
> > > > to
> > > > > > @ootao*steve's authority, and then the same resolution call
a
> > > > > minute
> > > > > > later
> > > > > > will return a different verifiable CID. So, indeed, a client
> > > > can
> > > > > get
> > > > > > back a
> > > > > > different XRI authority when making two consecutive
> > > > (equivalent)
> > > > > > resolution
> > > > > > calls. But this is all fine and good because it is the way
> > > > that
> > > > > we
> > > > > > designed
> > > > > > Ref processing (a long, long time ago.) Given this behavior,
> > > > the
> > > > > > (CanonicalID) identity model is still sound, because, by
> > > > > definition,
> > > > > > the
> > > > > > second resolution call simply returns a different XRI
> > > > authority.
> > > > > >
> > > > > >
> > > > > >
> > > > > > As for the CanonicalID being optional, <CanonicalID>
> > > > is
> > > > > > simply an
> > > > > > element in the XML metadata that one XRI authority uses to
> > > > > describe
> > > > > > another.
> > > > > > The first authority can choose to use it or not. If it does
> > > > not
> > > > > use
> > > > > > it, then
> > > > > > a Resolution client obviously cannot use the element to
> > > > > distinguish
> > > > > > authorities. No harm no foul. As for immutability: if
> > > > resolving
> > > > > two
> > > > > > XRIs
> > > > > > produce to different verifiable CanonicalIDs then, by
> > > > definition
> > > > > of
> > > > > > the
> > > > > > model, they address different authorities-two different
> > > > records
> > > > > in
> > > > > > Les'
> > > > > > global database.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I really respect and appreciate Les' effort to
> > > protect
> > > > > these
> > > > > > fundamentals. The introduction of GlobalID is a giant step
in
> > > > > the
> > > > > > wrong
> > > > > > direction. It is an attempt to define a more complicated
> > > > > identity
> > > > > > model in
> > > > > > the interest of solving a newly introduced use case. If that
> > > > use
> > > > > > case is
> > > > > > indeed important (which I doubt) then it should be solved
> > > > within
> > > > > the
> > > > > > existing model-not by trying to define a new one.
> > > > > >
> > > > > >
> > > > > >
> > > > > > ~ Steve
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > PS: For the typical disclaimer, I need to point out
> > > > that
> > > > > XRI
> > > > > > resolution supports many identity models, and resolution
> > > > clients
> > > > > may
> > > > > > not
> > > > > > care at all about using a CanonicalID in the fashion
> > > described
> > > > > > above.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > >
> > > > > > From: Chasen, Les [mailto:
> > > > > les.chasen@neustar.biz <mailto:les.chasen@neustar.biz>
> > <mailto:les.chasen@neustar.biz <mailto:les.chasen@neustar.biz>>
> > > > > > <mailto: les.chasen@neustar.biz
<mailto:les.chasen@neustar.biz>
> > <mailto:les.chasen@neustar.biz <mailto:les.chasen@neustar.biz>>> ]
> > > > > > Sent: Tuesday, August 14, 2007 12:16 AM
> > > > > > To: Drummond Reed; xri@lists.oasis-open.org
> > <mailto:xri@lists.oasis-open.org>
> > > <mailto:xri@lists.oasis-open.org
<mailto:xri@lists.oasis-open.org>>
> > > > > > <mailto: xri@lists.oasis-open.org
> > <mailto:xri@lists.oasis-open.org> <mailto:xri@lists.oasis-open.org
> > <mailto:xri@lists.oasis-open.org>>>
> > > > > > Subject: RE: [xri] CID changes in wd11
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi Drummond,
> > > > > >
> > > > > >
> > > > > >
> > > > > > Welcome back hope you had a nice vacation.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Yes CID has always been optional and we cannot do
> > > > > anymore
> > > > > > than
> > > > > > recommend that it be persistent. We have also never
> > > actually
> > > > > > spelled out
> > > > > > that it cannot change. However, the implication has always
> > > > been
> > > > > > there that
> > > > > > it is immutable. That is until the introduction of globalId
> > > > and
> > > > > the
> > > > > > specification, for the first time, stating that CID is
> > > > editable.
> > > > > I
> > > > > > think
> > > > > > this is a huge architectural mistake given where we are
> > > in the
> > > > > life
> > > > > > of XRI.
> > > > > > We have a base of applications out there, at our insistence,
> > > > > using
> > > > > > CID as a
> > > > > > persistent key. It is too late to change that now.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I therefore propose that we take CID back to where it
> > > > > was in
> > > > > > WD10
> > > > > > and add extra text to codify that it should be left
> > > immutable.
> > > > > > Personally I
> > > > > > would make it a MUST requirement but I recognize for the
same
> > > > > reason
> > > > > > that it
> > > > > > is an optional field and persistence is a recommendation we
> > > > > cannot
> > > > > > really
> > > > > > require that it MUST be immutable. So a SHOULD be immutable
> > > > is
> > > > > > fine.
> > > > > >
> > > > > >
> > > > > >
> > > > > > contact: =les < http://xri.net/=les <http://xri.net/=les>
> > > > > <http://xri.net/=les> >
> > > > > >
> > > > > > voice : =les/(+phone)
> > > > < http://xri.net/=les/%28+phone%29>
> > > > > >
> > > > > > chat: =les/skype/chat <
> > > http://xri.net/=les/skype/chat < http://xri.net/=les/skype/chat>
> > > > > > <http://xri.net/=les/skype/chat> >
> > > > > >
> > > > > > pibb me =les/+pibb < http://xri.net/=les/+pibb>
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > >
> > > > > > From: Drummond Reed
> > > > > > [mailto: drummond.reed@cordance.net
> > <mailto:drummond.reed@cordance.net>
> > > <mailto:drummond.reed@cordance.net
> <mailto:drummond.reed@cordance.net>>]
> > > > > > Sent: Tuesday, August 14, 2007 1:37 AM
> > > > > > To: Chasen, Les; xri@lists.oasis-open.org
> > <mailto:xri@lists.oasis-open.org>
> > > <mailto:xri@lists.oasis-open.org
<mailto:xri@lists.oasis-open.org>>
> > > > > > <mailto:xri@lists.oasis-open.org
> > <mailto:xri@lists.oasis-open.org> <mailto:xri@lists.oasis-open.org
> > <mailto:xri@lists.oasis-open.org>> >
> > > > > > Subject: RE: [xri] CID changes in wd11
> > > > > >
> > > > > >
> > > > > >
> > > > > > Les,
> > > > > >
> > > > > >
> > > > > >
> > > > > > I have just returned from vacation and am still
> > > > catching
> > > > > up
> > > > > > on email
> > > > > > and the minutes of the meetings while I was gone. But
> > > > regarding
> > > > > your
> > > > > > point
> > > > > > about CIDs, here's some initial thoughts:
> > > > > >
> > > > > >
> > > > > >
> > > > > > 1) First, CanonicalID, like all synonym elements,
> > > has
> > > > > always
> > > > > > been
> > > > > > optional. There's no requirement than an XRD MUST assert an
> > > > > > CanonicalID.
> > > > > > It's RECOMMENDED, but for obvious reasons it's not
> > > REQUIRED at
> > > > > the
> > > > > > spec
> > > > > > level because some users of XRDS architecture don't need
> > > > > > CanonicalIDs at
> > > > > > all.
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2) Second, there is no requirement that a CanonicalID
> > > > > value
> > > > > > be
> > > > > > persistent. Again, it's RECOMMENDED, but not REQUIRED, as
> > > some
> > > > > > authorities
> > > > > > don't either want or need persistent identifiers.
> > > > > >
> > > > > >
> > > > > >
> > > > > > So my first point is that as much as it would be
> > > nice
> > > > > for
> > > > > > all XRDs
> > > > > > to: a) have a CanonicalID value, and b) make it a persistent
> > > > > > identifier that
> > > > > > never changes, we have never (in WD10 or any earlier draft)
> > > > > required
> > > > > > for
> > > > > > either to be true. An authority has always been able to
> > > assert
> > > > > any
> > > > > > CanonicalID value they want, and change it anytime they
> > > want.
> > > > > The
> > > > > > only
> > > > > > change from WD10 to WD11 is that the cardinality of
> > > > CanonicalID
> > > > > went
> > > > > > from
> > > > > > zero-or-more to zero-or-one.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Secondly, the main purpose of XRI synonym
> > > architecture
> > > > > is to
> > > > > > model
> > > > > > the real world in which a resource may have any number of
> > > > > > identifiers
> > > > > > assigned to it by any number of authorities. Each of these
> > > > > > identifiers may
> > > > > > be either reassignable or persistent. WD11 is the first
> > > draft
> > > > in
> > > > > > which we
> > > > > > have, in section 11 and specifically in Table 23 (page 60 of
> > > > the
> > > > > > PDF), fully
> > > > > > captured the semantics necessary for an authority to assert
> > > > the
> > > > > set
> > > > > > of
> > > > > > identifiers it uses to identify a resource in such a manner
> > > > that
> > > > > > client
> > > > > > applications have all the metadata they need to
> > > understand how
> > > > > to
> > > > > > consume
> > > > > > those identifiers to maintain a reference to the resource.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Your specific concern is that client applications be
> > > > > able to
> > > > > > know
> > > > > > which identifier they can use as a persistent global foreign
> > > > key
> > > > > for
> > > > > > a
> > > > > > resource. Table 23 explains that of the five synonym
> > > elements
> > > > > > available,
> > > > > > only three fit the requirements of a global foreign key:
> > > > > > CanonicalID,
> > > > > > GlobalID, and Ref. LocalID and Backref do not meet the
> > > > > requirements
> > > > > > because:
> > > > > >
> > > > > >
> > > > > >
> > > > > > * LocalID is relative and not absolute.
> > > > > >
> > > > > > * Backref is an assertion that another authority is
> > > > > > referencing the
> > > > > > synonyms in the current XRD to identify the resource.
> > > > > >
> > > > > >
> > > > > >
> > > > > > However the other three - CanonicalID, GlobalID, and
> > > > Ref
> > > > > --
> > > > > > *all*
> > > > > > can meet the requirements of global foreign keys for a
> > > > resource.
> > > > > > This begs
> > > > > > the question: why have three XRD synonym elements that
> > > can all
> > > > > serve
> > > > > > as
> > > > > > global foreign keys?
> > > > > >
> > > > > >
> > > > > >
> > > > > > Table 23 provides the answer. GlobalID and Ref
> > > cleanly
> > > > > > separate
> > > > > > global keys for a resource into two categories for trust
> > > > > purposes:
> > > > > >
> > > > > >
> > > > > >
> > > > > > 1) Category #1 - GlobalIDs - are hierachical
> > > > identifiers
> > > > > > that are
> > > > > > assigned by the authority for the XRD and thus can be
> > > verified
> > > > > > hierachically.
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2) Category #2 - Refs - are polyarchical identifiers
> > > > > that
> > > > > > are
> > > > > > assigned by authorities OTHER than the authority for the XRD
> > > > and
> > > > > > which thus
> > > > > > must be verified polyarchically, i.e., by confirming the
> > > > > > corresponding
> > > > > > Backref.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Given that between these two categories, we've
> > > covered
> > > > > 100%
> > > > > > of the
> > > > > > use cases (to the best of my knowledge), what then is the
> > > > > purpose of
> > > > > > the
> > > > > > CanonicalID element? Why do we even need it?
> > > > > >
> > > > > >
> > > > > >
> > > > > > The answer is that, because an authority can assert
> > > > any
> > > > > > number of
> > > > > > GlobalIDs or Refs for a resource (the use cases for
asserting
> > > > > > multiple
> > > > > > GlobalIDs are pretty weak but the use cases for asserting
> > > > > multiple
> > > > > > Refs can
> > > > > > be very strong), the additional value of the CanonicalID
> > > > element
> > > > > is
> > > > > > that it
> > > > > > gives XRD authorities a way to assert which ONE of these
> > > > > multiple
> > > > > > global
> > > > > > foreign keys the authority RECOMMENDS client applications
use
> > > > to
> > > > > > maintain a
> > > > > > reference to the resource.
> > > > > >
> > > > > >
> > > > > >
> > > > > > So the net net is that the value(s) of the GlobalID
> > > > > > (zero-or-more),
> > > > > > Ref (zero-or-more), and the CanonicalID (zero-or-one)
> > > elements
> > > > > are
> > > > > > all
> > > > > > absolute identifiers that can serve as global foreign
> > > keys for
> > > > a
> > > > > > resource.
> > > > > > All the element tag tells you about these identifiers is:
> > > > > >
> > > > > >
> > > > > >
> > > > > > * Was it assigned by the authority for the XRD
> > > > > (GlobalID)?
> > > > > >
> > > > > > * Was it NOT assigned by the authority for the XRD
> > > > > (Ref)?
> > > > > >
> > > > > > * Of all the options, is it the recommended global
> > > > > foreign
> > > > > > key for
> > > > > > the resource (CanonicalID)?
> > > > > >
> > > > > >
> > > > > >
> > > > > > This reveals the precise reason that the value of a
> > > > > > CanonicalID
> > > > > > element in an XRD could change over time: the parent
> > > authority
> > > > > > learns that
> > > > > > the recommended global foreign key for a resource is
> > > different
> > > > > than
> > > > > > the one
> > > > > > the parent authority has heretofore been recommending. For
> > > > > example,
> > > > > > a parent
> > > > > > authority could initially publish:
> > > > > >
> > > > > >
> > > > > >
> > > > > > <XRDS>
> > > > > >
> > > > > > <XRD>
> > > > > >
> > > > > > <Query>*example</Query>
> > > > > >
> > > > > > <GlobalID>=!1</GlobalID>
> > > > > >
> > > > > >
> > > > > > <Ref> http://example.com/example/resource#1234</Ref>
> > > > > >
> > > > > >
> > > > > > <Ref> https://example.com/example/resource#1234
> > <https://example.com/example/resource#1234>
> > > > > > <https://example.com/example/resource#1234
> > > <https://example.com/example/resource#1234
> > <https://example.com/example/resource#1234>>> </Ref>
> > > > > >
> > > > > >
> > > > > >
> > > > > <CanonicalID>https://example.com/example/resource#1234
> > <https://example.com/example/resource#1234></CanonicalID>
> > > > > >
> > > > > > </XRD>
> > > > > >
> > > > > > </XRDS>
> > > > > >
> > > > > >
> > > > > >
> > > > > > But the resource identified by these three synonyms
> > > > may
> > > > > lose
> > > > > > control
> > > > > > over the domain name " example.com <http://example.com>
> > <http://example.com> <
> > > http://example.com> ". In
> > > > > this
> > > > > > case, even though
> > > > > > https://example.com/example/resource#1234
> > > > > > < https://example.com/example/resource#1234
> > <https://example.com/example/resource#1234>> is a persistent
> > > > identifier
> > > > > (see
> > > > > > below), the authority may decide that at that point it is
> > > > better
> > > > > to
> > > > > > recommend a different persistent identifier as the
> > > > CanonicalID.
> > > > > Thus
> > > > > > the XRD
> > > > > > could change to:
> > > > > >
> > > > > >
> > > > > >
> > > > > > <XRDS>
> > > > > >
> > > > > > <XRD>
> > > > > >
> > > > > > <Query>*example</Query>
> > > > > >
> > > > > > <GlobalID>=!1</GlobalID>
> > > > > >
> > > > > >
> > > > > > <Ref> http://example.com/example/resource#1234</Ref>
> > > > > >
> > > > > >
> > > > > > <Ref> https://example.com/example/resource#1234
> > <https://example.com/example/resource#1234>
> > > <https://example.com/example/resource#1234>
> > > > > > <https://example.com/example/resource#1234
> > <https://example.com/example/resource#1234>> </Ref>
> > > > > >
> > > > > >
> > > <CanonicalID>=!1</CanonicalID>
> > > > > >
> > > > > > </XRD>
> > > > > >
> > > > > > </XRDS>
> > > > > >
> > > > > >
> > > > > >
> > > > > > Note that the identifier "
> > > > > > https://example.com/example/resource#1234";
> > > > > > did NOT go away as a persistent global foreign key for the
> > > > > resource.
> > > > > > It's
> > > > > > still there as a Ref, just as it was in the first
> > > example. The
> > > > > only
> > > > > > change
> > > > > > is that the CanonicalID now points to a different global
> > > > foreign
> > > > > key
> > > > > > as the
> > > > > > preferred one.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Again note that NONE of the XRI synonym elements has
> > > > the
> > > > > > semantics
> > > > > > that the identifier value MUST be persistent (not in WD11,
> > > > WD10,
> > > > > or
> > > > > > any
> > > > > > earlier draft). The way for a consuming application to tell
> > > > > whether
> > > > > > the
> > > > > > identifier is asserted as persistent is to check for either
> > > > XRI
> > > > > > persistence
> > > > > > semantics (! syntax for i-numbers) or URI persistence
> > > > semantics
> > > > > > (urn: or
> > > > > > other persistent URI schemes).
> > > > > >
> > > > > >
> > > > > >
> > > > > > ***********
> > > > > >
> > > > > > I hope this helps. Clearly this issue is deep enough
> > > > > that it
> > > > > > can
> > > > > > benefit more from direct phone or f2f discussion than from
> > > > > email. I
> > > > > > nominate
> > > > > > it for the agenda for this week's TC call, but in the
> > > meantime
> > > > > feel
> > > > > > free to
> > > > > > call me if you want to discuss further.
> > > > > >
> > > > > >
> > > > > >
> > > > > > =Drummond
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > >
> > > > > > From: Chasen, Les
> > > > > [mailto: les.chasen@neustar.biz
<mailto:les.chasen@neustar.biz>
> > <mailto:les.chasen@neustar.biz <mailto:les.chasen@neustar.biz>>]
> > > > > > Sent: Monday, August 13, 2007 3:16 PM
> > > > > > To: xri@lists.oasis-open.org
<mailto:xri@lists.oasis-open.org>
> > > <mailto:xri@lists.oasis-open.org
<mailto:xri@lists.oasis-open.org>>
> > > > > > <mailto: xri@lists.oasis-open.org
> > <mailto:xri@lists.oasis-open.org> <mailto:xri@lists.oasis-open.org
> > <mailto:xri@lists.oasis-open.org>>>
> > > > > > Subject: [xri] CID changes in wd11
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi all -
> > > > > >
> > > > > >
> > > > > >
> > > > > > After reviewing the latest wd11 I have one major
> > > > > concern.
> > > > > > This
> > > > > > version allows a CID to be changed after it is already set.
> > > > I
> > > > > > believe that
> > > > > > this is a big mistake. The CID is the persistent identifier
> > > > for
> > > > > the
> > > > > > queried
> > > > > > XRD. We need to ensure that once an XRD has a CID that that
> > > > CID
> > > > > > identifies
> > > > > > that XRD forever.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I have always thought of the CID as a primary key to
> > > > the
> > > > > > global
> > > > > > database we have created with XRI resolution. Client
> > > > > applications
> > > > > > have been
> > > > > > and are being written that depend on the value of this
> > > primary
> > > > > key
> > > > > > for the
> > > > > > mapping of an identity described by an XRDS to their
> > > internal
> > > > > > account
> > > > > > structure. If we allow this primary key to be changed we
> > > have
> > > > > > caused a
> > > > > > major data integrity problem.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I propose that the definition of CID not only revert
> > > > > back to
> > > > > > the
> > > > > > WD10 definition but we also more strongly codify that a CID
> > > > once
> > > > > set
> > > > > > should
> > > > > > never be changed.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > >
> > > > > >
> > > > > > Les
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > contact: =les < http://xri.net/=les
> > > > > <http://xri.net/=les> >
> > > > > >
> > > > > > voice : =les/(+phone) <
> > > > > http://xri.net/=les/%28+phone%29>
> > > > > >
> > > > > > chat: =les/skype/chat <
> > > http://xri.net/=les/skype/chat < http://xri.net/=les/skype/chat>
> > > > > > <http://xri.net/=les/skype/chat> >
> > > > > >
> > > > > > pibb me =les/+pibb < http://xri.net/=les/+pibb>
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > =peterd ( http://xri.net/=peterd )
> > >
> > >
> > >
> > >
> > >
> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]