RE: [xri] RE: Direct descendant vs. family descendant CIDs (was RE: [xri] Minutes: Special XRI TC Telecon Noon PT Friday 2007-08-24)

If you register two inames with the same
inumber then you have *truly*
created synonyms.  These three identifiers all are keys for the same
XRDS.  In the GRS they are all tied to the same entity called an
authority.  The localid is always the local portion of the
inumber.   (I’m sure everyone knows this but just in case i-number
is cid).

 

Based on my understanding of the need for
EquivId it is not related to localId.  EquivId is demonstrating equivalence
with an external identifier, i.e. polyarchical.  localId is simply that …
local to the current authority.

 

 

 

 

contact: =les

voice: =les/(+phone)

chat: =les/skype/chat

pibb me  =les/+pibb

 

 

 

 

From:
 [mailto:] On Behalf Of Markus Sabadello

Sent: Saturday, August 25, 2007
6:54 PM

To: Chasen, Les

Cc: Drummond Reed;


Subject: Re: [xri] RE: Direct
descendant vs. family descendant CIDs (was RE: [xri] Minutes: Special XRI TC
Telecon Noon PT Friday 2007-08-24)

 

I think I recall reading somewhere that if I registered two i-names under the
same i-number (like I have with @free and @on-line), then it would be
appropriate for their XRDs to have <LocalID>s referencing each other
(*on-line and *free). The only reason why the GRS does NOT do it is for privacy
reasons I think? 

It seems the new EquivID is really a superset of LocalID. I.e. for every
LocalID you could also have an EquivID with the absolute version of the same
identifier...

Markus

On 8/25/07, Chasen,
Les <>
wrote:

That is a good question … I never liked the tag. 
If it has morphed into something that represents any local synonym than that is
even more reason that it cannot be used in CID validation.  

 

contact: =les

voice : =les/(+phone)

chat: =les/skype/chat

pibb me 
=les/+pibb

 

 

 

 

From: 
[mailto:
] On Behalf Of Markus
Sabadello

Sent: Saturday, August 25, 2007 5:27
PM

To: Chasen, Les

Cc: Drummond Reed; 

Subject: Re: [xri] RE: Direct
descendant vs. family descendant CIDs (was RE: [xri] Minutes: Special XRI TC
Telecon Noon PT Friday 2007-08-24)

 

The way I always understood LocalID was that it not only contains the local
part of the CID, but also other local synonyms. If it was just for the CID,
then why did you guys introduce it in the first place?

Markus 

On
8/25/07, Chasen, Les <>
wrote:

> -----Original Message-----

> From: Drummond Reed [mailto:]

> Sent: Friday, August 24, 2007 8:39 PM

> To: Chasen, Les; 

> Subject: Direct descendant vs. family descendant CIDs (was RE: [xri]

> Minutes: Special XRI TC Telecon Noon PT Friday 2007-08-24)

>

> Les, this requires that each CID being a direct child of the parent 

CID.

> That's fine if we decide to require that. What we discussed on the

call is

> an equally veriable but more flexible rule where each CID must consist

of

> valid subsegments from all of its parents. 

[Chasen, Les] I apologize if I missed when we in the TC we discussed or

traded emails on this new proposal.  I thought until yesterday we
were

sticking with the original intent which you are calling direct 

descendants below.  I simply do not recall ever discussing something

else.

>

> For example, if @cordance has cid = @!1 but also has LocalID !2 and

!3,

> and

> @cordance*drummond has LocalID !4, then any of the following three 

> identifiers would be verifiable CanonicalIDs for @cordance*drummond:

>

>       @!1!4

>       @!2!4

>       @!3!4

[Chasen, Les]

What happens if @nuestar's cid is @!2 and @ootao has cid @!3? 

This does bring up another question.  As I recall the intent of
localId

it was to contain the local portion of the absolute cid.  Since we
are

changing the cardinality of cid to be 0-1 should we change the

cardinality of the localId to 0-1?

>

> I'd call this approach "family descendants" and the other
approach

"direct

> descendants". The only reason I suggest considering family
descendants 

is

> that it provides more flexibility in the assignment of CanonicalIDs at

> lower

> levels in the resolution chain. OTOH, if we want to be more

restrictive

> and

> require direct descendants, that's fine too (I'm pretty sure they 

would be

> easier and faster to verify).

>

> How do others feel?

>

> =Drummond

>

> > -----Original Message-----

> > From: Chasen, Les [mailto: ]

> > Sent: Friday, August 24, 2007 4:26 PM

> > To: Drummond Reed; 

> > Subject: RE: [xri] Minutes: Special XRI TC Telecon Noon PT Friday 

2007-

> 08-

> > 24

> >

> > We also got sidetracked into a conversation on CID verification that

I

> > think will need to get re-visited.  Drummond explained how
it is

> > possible for CID verification to pass if a parent XRD does not 

contain a

> > CID while the child does.  The exact scenario discussed was

> > @cordance*Drummond*home where @cordance and *home have CIDs but

> > *Drummond does not ... but cid verification still passes. 

> >

> > I think this is wrong and against the original intent of cid

> > verification.  We MUST verify that every XRD in a
hierarchical chain

> > verify with the parent XRD.  This means that every XRD must
have a 

CID

> > and each CID must contain the parent node in it's fully qualified

CID.

> > So if @cordance has cid = @!1 then *Drummond must have a CID that

begins

> > with @!1.  If we assume *drummond's cid is @!1!2 then *home
needs to 

> > have a cid that starts with @!1!2.

> >

> > contact: =les

> > sip: =les/(+phone)

> > chat: =les/skype/chat

> >

> >

> >

> > > -----Original Message----- 

> > > From: Drummond Reed [mailto:]

> > > Sent: Friday, August 24, 2007 6:12 PM

> > > To: 

> > > Subject: [xri] Minutes: Special XRI TC Telecon Noon PT Friday

> > 2007-08-24

> > >

> > > Following are the minutes of the special unofficial XRI TC
telecon 

> > held

> > > at:

> > >

> > > Date:  Friday, 24 August 2007 USA

> > > Time:  12:00PM - 1:00PM Pacific Time

> > >

> > > TO ACCESS THE AUDIO CONFERENCE: 

> > >     Dial In Number: 571-434-5750

> > >     Conference ID: 5474

> > >

> > > ATTENDING

> > >

> > > Wil Tan

> > > Markus Sabadello

> > > Les Chasen

> > > Drummond Reed

> > >

> > >

> > > The subject of the call was the current synonym semantics
proposal

at:

> > >

> > >   http://wiki.oasis-open.org/xri/XriCd02/SynonymSemantics

> > >

> > > Key points from the call:

> > >

> > > * We briefly discussed Bill Barnhill's proposal to the list but 

the

> > > conclusion was that: a) we don't want to change the definitions
of

> > > LocalID,

> > > CanonicalID, and Ref due both to the installed base and to the

fact

> > that 

> > > there is (now) relatively strong consensus on the use of these

synonym

> > > elements (see below), and b) adding attributes to a single
synonym

> > element

> > > does not enable control at the XML schema level of cardinality, 

which

> > is

> > > important for elements such as CanonicalID (and the proposed

UseCID).

> > >

> > > * We had a long discussion about the underlying needs for

applications 

> > to

> > > store a persistent identifier for a resource, touching upon many

> > different

> > > potential scenerios: when they are constrained (by schema or
data

> > store) 

> > > to

> > > having only one, when they can keep alternates, when they need
to

know

> > > equivalence relationships, etc.

> > >

> > > * We also discussed the use cases that require a target
resources 

to

> > > merge,

> > > migrate, or simply associate identifiers, such as an individual

moving

> > > from

> > > one community to another or two businesses merging.

> > > 

> > > * We established that have consensus about the purpose and uses
of

> > Ref.

> > > The

> > > only inputs that determined whether a Ref is following or not
are

the

> > > QXRI, 

> > > the refs= parameter, and the service endpoint selection

parameters.

> > The

> > > cid

> > > parameter will NOT affect affecting Ref processing.

> > >

> > > * We also have consensus that EquivID should have zero-or-more 

> > > cardinality,

> > > is used to express equivalence relationships between
identifiers,

and

> > can

> > > be

> > > used in conjunction with the priority attribute to express the 

> > priority of

> > > such equivalence assertions.

> > >

> > > * Where we do not have consensus yet is if or how an XRD should

enable

> > > expression of a "stronger than equivalence" mapping
relationship 

> > between

> > > two

> > > identifiers. Such a relationship might be called "directional",

> > > "precessor/successor", "migration",
"replacement", "preference", 

> > > "redirect",

> > > or many other terms.

> > >

> > > * Les proposed that we define a PreferredID element for this

purpose

> > with

> > > roughly the following definition: "The purpose of this tag
is to 

> > express

> > > the

> > > preferred identifier for the target resource if that preferred

> > identifier

> > > is

> > > not the QXRI or CanonicalID. It is recommended that applications

> > retain

> > > this

> > > identifier in their local account for future reference to this

> > resource."

> > >

> > > * Drummond proposed that the core underlying motivation is to 

support

> > the

> > > need of XRD authors to inform consuming applications that they

should

> > > associate two primary global foreign keys for a resource.

> > >

> > > * After 2.5 hours of discussion, we agreed that next step is for

all

> > TC

> > > members who have specific views on this issue to post their
views

to

> > the

> > > SynonymSemantics page of the wiki. 

> > >

> > > * There will be another followup call on this topic on the same

> > telecon

> > > number at 8AM PT/11AM ET Monday August 27th.

> > >

> > > =Drummond 

> > >

> > >

>