OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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 <les.chasen@neustar.biz> 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: markus.sabadello@gmail.com [mailto: markus.sabadello@gmail.com] On Behalf Of Markus Sabadello
Sent: Saturday, August 25, 2007 5:27 PM
To: Chasen, Les
Cc: Drummond Reed; xri@lists.oasis-open.org
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 <les.chasen@neustar.biz> wrote:

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Friday, August 24, 2007 8:39 PM
> To: Chasen, Les; xri@lists.oasis-open.org
> 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: les.chasen@neustar.biz]
> > Sent: Friday, August 24, 2007 4:26 PM
> > To: Drummond Reed; xri@lists.oasis-open.org
> > 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:drummond.reed@cordance.net]
> > > Sent: Friday, August 24, 2007 6:12 PM
> > > To: xri@lists.oasis-open.org
> > > 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
> > >
> > >
>








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]