See my comments inline:
Drummond Reed wrote:
> Let me explain why I'm comfortable with the "weaker" semantics for
> MapToID/MapFromID that Wil proposes.
>
Great!
> First, I agree with Les's point (two messages down) that MapToID/MapFromID
> should, like EquivID, stay independent from resolution semantics. Their
> purpose is strictly identification semantics.
>
> For this purpose, the key difference between EquivID and MapToID/MapFromID
> is directionality. EquivID is non-directional and purely p2p. It doesn't
> suggest to a consuming application anything more than "also known as".
> Consuming apps can build or not build tables of EquivID mappings as needed,
> but if they do build them, there is no directionality implied.
>
> By contrast, MapToID/MapFromID is strictly directional. As Wil puts it, they
> enable express of "I would like to map to this other identifier" and "I
> allow this other identifier to map to me". Again, consuming apps can build
> or not build MapToID/MapFromID mapping tables as needed, but if they do
> build them, they know exactly the directionality implied. As Wil notes, the
> resolver can still verify the mapping even though the spec doesn't dictate
> what "map" means.
>
> My feeling is that as long as non-directional and directional synonyms are
> supported at the spec level, then specific identifier communities can set
> policy around the uses these elements as they need. If we discover through
> practice that additional semantics needed in the future, we can tackle that
> when we get there.
>
I understand and agree that EquivID is p2p and non-directional, while
MapToID/MapFromID are directional. I also understand that it would be
Nice to be able to express an AKA relationship using a non-directional
element. However, I'm not sure if the use case is a strong one.
Generally, I would prefer to leave these to an extension (the X in XRDS)
since it doesn't affect the core resolution behavior; my compiler has
detected an "unreferenced local variable named EquivID".
I also don't understand how you could use EquivID to express directional
equivalence without MapToID/MapFromID. Unless, of course, you encode
directionality into an attribute of EquivID, but that IMO is less
preferable to having separate elements.
=wil
> =Drummond
>
>
>> -----Original Message-----
>> From: Chasen, Les [mailto:]
>> Sent: Monday, August 20, 2007 3:52 PM
>> To: Tan, William
>> Cc: Drummond Reed; Markus Sabadello; Gabe Wachob; Davis, Peter; William
>> Barnhill; ; XRI TC; Andy Dale
>> 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; ; 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:]
>>>> *Sent:* Monday, August 20, 2007 4:07 PM
>>>> *To:* Chasen, Les; 'Markus Sabadello'; Tan, William
>>>> *Cc:* 'Gabe Wachob'; Davis, Peter; 'William Barnhill';
>>>> ; '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:]
>>>> *Sent:* Monday, August 20, 2007 10:10 AM
>>>> *To:* Markus Sabadello; Tan, William
>>>> *Cc:* Drummond Reed; Gabe Wachob; Davis, Peter; William Barnhill;
>>>> ; 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:*
>>>>
>> [mailto:]
>>
>>>> *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; ; 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* <
>>>> <mailto:>> 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:*
>>>>>
>>>> <mailto:>
>>>>
>> [mailto:
>>
>>>> <mailto:>]
>>>>
>>>>> *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;
>>>>> <mailto:>; 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* <
>>>>>
>>>> <mailto:>
>>>>
>>>>> <mailto:
>>>>>
>>>> <mailto:>>> 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:*
>>>>>
>>>> <mailto:>
>>>>
>> <mailto:
>>
>>>> <mailto:>>
>>>>
>>>>> [mailto:
>>>>>
>>> <mailto:>
>>>
>>>>> <mailto:
>>>>>
>>>> <mailto:>>] *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;
>>>>> <mailto:>
>>>>>
>>>> <mailto: <mailto:>>;
>>>> 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* <
>>>>>
>>>> <mailto:>
>>>>
>>>>> <mailto: <mailto:>>>
>>>>>
>>> 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:
>>>>>>
>>>> <mailto:>
>>>>
>>>>> <mailto: <mailto:>>]
>>>>>
>>>>>> Sent: Thursday, August 16, 2007 10:04 AM
>>>>>> To: 'Peter Davis'; 'Drummond Reed'; 'Les Chasen';
>>>>>> <mailto:>
>>>>>>
>>>> <mailto: <mailto:>>;
>>>> 'William
>>>>
>>>>> Barnhill'
>>>>>
>>>>>> Cc: <mailto:>
>>>>>>
>>>> <mailto: <mailto:>>;
>>>>
>>> '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:
>>>>>>>
>>>> <mailto:>
>>>>
>>>>> <mailto:
>>>>>
>> <mailto:>>]
>>
>>>>>>> Sent: Thursday, August 16, 2007 5:51 AM
>>>>>>> To: Drummond Reed; Les Chasen;
>>>>>>>
>>>> <mailto:>
>>>>
>>>>> <mailto:
>>>>>
>> <mailto:>>;
>>
>>>> William
>>>>
>>>>>> Barnhill
>>>>>>
>>>>>>> Cc: <mailto:>
>>>>>>>
>>>> <mailto:
>>>>
>> <mailto:>>;
>>
>>> 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" <
>>>>>>>
>>>> <mailto:>
>>>>
>>>>> <mailto:
>>>>>
>>> <mailto:>>>
>>>
>>>>>> 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:
>>>>>>>>
>>>> <mailto:>
>>>>
>>>>> <mailto: <mailto:>>]
>>>>>
>>>>>>>> Sent: Wednesday, August 15, 2007 2:59 PM
>>>>>>>> To:
>>>>>>>>
>> <mailto:>
>>
>>>> <mailto: <mailto:>>;
>>>>
>>>>> <mailto:>
>>>>>
>> <mailto:
>>
>>>> <mailto:>>
>>>>
>>>>>>>> Cc:
>>>>>>>>
>>> <mailto:>
>>>
>>>>> <mailto:
>>>>>
>>>> <mailto:>>;
>>>> <mailto:>
>>>>
>>>>> <mailto:
>>>>>
>> <mailto:>>;
>>
>>>>>>>> <mailto:>
>>>>>>>>
>>>> <mailto: <mailto:>>;
>>>>
>>>>> <mailto:> <mailto:
>>>>>
>>>> <mailto:>>
>>>>
>>>>>>>> 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:
>>>>>>>>
>>>> <mailto:>
>>>>
>>>>> <mailto:
>>>>>
>>>> <mailto:>> <
>>>> <mailto:>
>>>>
>>>>> <mailto:
>>>>>
>>> <mailto:>>>
>>>
>>>>>>>> To: Barnhill, William <
>>>>>>>>
>>>> <mailto:>
>>>>
>>>>> <mailto:
>>>>>
>> <mailto:>>>
>>
>>>>>>>> Cc: Drummond Reed <
>>>>>>>>
>>>> <mailto:>
>>>>
>>>>> <mailto:
>>>>>
>>>> <mailto:>>>; Steven Churchill
>>>>
>>>>>>>> < <mailto:>
>>>>>>>>
>>>> <mailto:
>>>>
>> <mailto:>>>;
>>
>>>>> Chasen, Les;
>>>>>
>>>> <mailto:> <mailto:
>>>> <mailto:>>
>>>>
>>>>>>>> < <mailto:>
>>>>>>>>
>>>> <mailto:
>>>>
>> <mailto:>>>;
>>
>>>>> Andy Dale < <mailto:>
>>>>>
>> <mailto:
>>
>>>> <mailto:>>>
>>>>
>>>>>>>> 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 <
>>>>>>>>
>>>> <mailto:>
>>>>
>>>>> <mailto:
>>>>>
>> <mailto:>>>
>>
>>>> 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:>
>>>>>>>
>>>> <mailto: <mailto:>>
>>>>
>>>>>>>> <mailto:
>>>>>>>>
>>>> <mailto:> <mailto:
>>>> <mailto:>>>
>>>>
>>>>>>>> Booz | Allen | Hamilton i-name: = Bill.Barnhill
>>>>>>>> "Delivering results that endure"
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ________________________________
>>>>>>>>
>>>>>>>> From:
>>>>>>>>
>>>> <mailto:>
>>>>
>>>>> <mailto:
>>>>>
>>> <mailto:>>
>>>
>>>>>>> <mailto:
>>>>>>>
>>>> <mailto:>
>>>>
>> <mailto:
>>
>>>> <mailto:>>>
>>>>
>>>>>>>> [mailto:
>>>>>>>>
>>>> <mailto:>
>>>>
>>>>> <mailto:
>>>>>
>>> <mailto:>>
>>>
>>>>>> <mailto:
>>>>>>
>>>> <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:>
>>>>>
>> <mailto:
>>
>>>> <mailto:>>
>>>>
>>>>>>>> <mailto: <mailto:-
>>>>>>>>
>>> open.org>
>>>
>>>>> <mailto:
>>>>>
>> <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 <
>>>>>>>>
>>>> <mailto:>
>>>>
>>>>> <mailto:
>>>>>
>>>> <mailto:>>> 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:
>>>>>>>>
>>>> <mailto:> <mailto:
>>>> <mailto:>>]
>>>>
>>>>>>>> Sent: Tuesday, August 14, 2007 10:46 AM
>>>>>>>> To: 'Chasen, Les'; 'Drummond Reed'; -
>>>>>>>>
>>>>>>> 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:
>>>>>>>>
>>>>>>> <mailto:>
>>>>>>>
>>>> <mailto: <mailto:>>
>>>>
>>>>>>>> <mailto:
>>>>>>>>
>> <mailto:>
>>
>>>> <mailto: <mailto:>>> ]
>>>>
>>>>>>>> Sent: Tuesday, August 14, 2007 12:16 AM
>>>>>>>> To: Drummond Reed;
>>>>>>>>
>>>> <mailto:>
>>>>
>>>>> <mailto:
>>>>>
>> <mailto:>>
>>
>>>>>>>> <mailto:
>>>>>>>>
>>>> <mailto:> <mailto:
>>>> <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>
>>>>>>>>
>>>>>>> <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:
>>>>>>>>
>>>> <mailto:>
>>>>
>>>>> <mailto:
>>>>>
>>> <mailto:>>]
>>>
>>>>>>>> Sent: Tuesday, August 14, 2007 1:37 AM
>>>>>>>> To: Chasen, Les;
>>>>>>>>
>>>> <mailto:>
>>>>
>>>>> <mailto:
>>>>>
>> <mailto:>>
>>
>>>>>>>> <mailto:
>>>>>>>>
>>>> <mailto:> <mailto:
>>>> <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>
>>>>
>>>>>>>> <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:
>>>>>>>
>> <mailto:>
>>
>>>> <mailto: <mailto:>>]
>>>>
>>>>>>>> Sent: Monday, August 13, 2007 3:16 PM
>>>>>>>> To:
>>>>>>>>
>> <mailto:>
>>
>>>>> <mailto:
>>>>>
>> <mailto:>>
>>
>>>>>>>> <mailto:
>>>>>>>>
>>>> <mailto:> <mailto:
>>>> <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>
>>>>>
>>>>>>>> <http://xri.net/=les/skype/chat> >
>>>>>>>>
>>>>>>>> pibb me =les/+pibb < http://xri.net/=les/+pibb>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> =peterd ( http://xri.net/=peterd )
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>
>
>
