RE: [xri] ED04 synonym proposal (was RE: [xri] CID changes in wd11)

["Drummond Reed" <drummond.reed@cordance.net>]

See inline.

> -----Original Message-----
> From: Chasen, Les [mailto:les.chasen@neustar.biz]
> Sent: Wednesday, August 22, 2007 11:30 AM
> To: Drummond Reed; Tan, William
> Cc: XRI TC; Andy Dale
> Subject: RE: [xri] ED04 synonym proposal (was RE: [xri] CID changes in
> wd11)
> 
> So I think you are saying simply that using EquivId I can establish that
> one XRD is equivalent to another XRD.  However that does not mean that
> the other XRD is equivalent to the first XRD.  @neustar*les may state
> that he is equivelelnt to =les with out any claim of =les being
> equivalent to @neustar*les.  In other words this is a one-way claim of
> synonymy between two XRDs.
> 
> OTOH, mapToId/mapFromId is also declaring synonymy between two XRDs but
> one that establishes a two-way claim.
> 
> I honestly do not see a need to have both of these attributes.  They
> seem to be close enough in meaning to almost be redundant.  I would
> personally just have EquivId (because it is a more descriptive term)
> with the ability to validate a two-way claim.  For example: XRD 1 has an
> EquivId that points to XRD 2 that establishes a one-way claim.  This may
> be fine for some consuming applications.  For those that need something
> stronger they could resolve for XRD 2 and look for another EquivId back
> to XRD 1.  This establishes a two-way claim.

Yes, that would establish a two-way peer-to-peer claim. But EquivID does not
give you a way to express either a one-way or two-way predecessor/successor
claim, i.e., a claim that says a predecessor ID should be mapped to a
successor ID. That's the purpose of the MapToID element (one way,
predecessor-to-successor) and MapFromID (other way,
successor-to-predecessor).

> With that said, I do not feel strongly enough about this.  If the TC is
> ok with it I am ok with it.

Cool. We'll discuss on the telecon tomorrow.

> One note, You also add the additional statement for MapToId that the
> consuming application should use the CID (or QXRI) that is in the
> MapToId as the identifier for the first XRD.  It seems to me that this
> implies that the XRD referred to by that MapToId is the successor XRD
> and therefore the first XRD should not be used for service selection.  I
> am not sure you can really do that if we do not change resolution logic.

I completely agree that neither EquivID or MapToID/MapFromID should change
resolution logic. That is the exclusive province of the Ref element. MapToID
is simply instructing consuming applications that there is a successor
identifier for the target resource. It DOES NOT mean that you can't use the
current XRD (the one asserting the MapToID) to describe service endpoints
for the resource. If the XRD author wants that to be true, the author can
replace those service endpoints with a Ref element. So instead of...

<XRD>
	<Query>*example</Query>
	<CanonicalID>@!1!2</CanonicalID>
	<MapToID>=!5</MapToID>
	<Service>
		...first service endpoint...
	</Service>
	<Service>
		...second service endpoint...
	</Service>
	<Service>
		...etc...
	</Service>
</XRD>

...the XRD author could create:

<XRD>
	<Query>*example</Query>
	<CanonicalID>@!1!2</CanonicalID>
	<MapToID>=!5</MapToID>
	<Ref>=!5</MapToID></Ref>
</XRD>

Either approach is valid. Keeping Ref and MapToID (and EquivID) semantics
strictly separated seems like a really good idea to me, as it allows XRD
authors to control these behaviours very tightly with minimum chance for
misinterpretation.

=Drummond 

> 
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Wednesday, August 22, 2007 2:06 AM
> > To: Chasen, Les; Tan, William
> > Cc: 'XRI TC'; 'Andy Dale'
> > Subject: RE: [xri] ED04 synonym proposal (was RE: [xri] CID changes in
> > wd11)
> >
> > Les, you're not missing anything, it's just the limited bandwidth of
> email
> > (and/or my inability to express exactly what I mean). I'll try to make
> it
> > clearer.
> >
> > When I say "non-directional", I mean that EquivID is expressing that
> > neither
> > the source ID or target ID should take precedence over the other --
> they
> > are
> > pure peers. And by "directional", I mean that MapToID is expressing
> that
> > the
> > target ID SHOULD take precedence over the source ID (and MapFromID
> > expresses
> > the inverse).
> >
> > So an EquivID element in XRD #1 pointing to the CanonicalID of XRD #2
> is
> > indeed a pointer from one to the other, but the semantics are only
> that
> > both
> > IDs represent the same resource, period. For example, the XRD for
> > @cordance*drummond could have an EquivID pointing to the QXRI or
> > CanonicalID
> > of =drummond and the semantic interpretation would simply be,
> "@cordance
> > says that @cordance*drummond represents the same resource as
> =drummond".
> >
> > A consuming application can simply take this statement at face value
> (for
> > example, if it has its own reasons to already trust @cordance as an
> > authority), or it can ask a resolver to verify it by seeing if it can
> find
> > a
> > statement saying that "= says that =drummond represents the same
> resource
> > as
> > @cordance*drummond" (meaning find an EquivID element in the XRD for
> > =drummond that points to the QXRI or CanonicalID of
> @cordance*drummond).
> >
> > However, if @cordance*drummond had a MapToID pointing to the QXRI or
> > CanonicalID of =drummond, that statement would express that "@cordance
> > says
> > that consuming applications should use [QXRI or CanonicalID] of
> =drummond
> > when referring to the resource known as @cordance*drummond". Again, a
> > consuming application can take this statement at face value, or it can
> ask
> > an XRI resolver to verify it to see if can find a statement saying
> > "=drummond says that consuming applications should use [QXRI or
> > CanonicalID]
> > of =drummond when referring to the resource known as
> @cordance*drummond"
> > (meaning find a MapFromID element in the XRD for =drummond that points
> to
> > the QXRI or CanonicalID of @cordance*drummond).
> >
> > Hope this helps,
> >
> > =Drummond
> >
> > > -----Original Message-----
> > > From: Chasen, Les [mailto:les.chasen@neustar.biz]
> > > Sent: Tuesday, August 21, 2007 8:21 PM
> > > To: Drummond Reed; Tan, William
> > > Cc: XRI TC; Andy Dale
> > > Subject: RE: [xri] ED04 synonym proposal (was RE: [xri] CID changes
> in
> > > wd11)
> > >
> > > I must be missing something ... I don't understand how you can say
> > > EquivId is non-directional.  It is defined in one XRD pointing to
> > > another XRD.  That seems directional to me.   XRD 1 is equivalent to
> XRD
> > > 2 but XRD 2 is not equivalent to XRD 1.
> > >
> > > contact: =les
> > > sip: =les/(+phone)
> > > chat: =les/skype/chat
> > >
> > >
> > > > -----Original Message-----
> > > > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > > > Sent: Tuesday, August 21, 2007 7:29 PM
> > > > To: Tan, William
> > > > Cc: 'XRI TC'; 'Andy Dale'
> > > > Subject: RE: [xri] ED04 synonym proposal (was RE: [xri] CID
> changes in
> > > > wd11)
> > > >
> > > > Wil, you wrote:
> > > >
> > > > > 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".
> > > >
> > > > My preference is strongly to include EquivID in the base XRD
> namespace
> > > > because this is the only means we will be providing to express
> > > > non-directional, p2p relationships between identifiers. Again, the
> > > purpose
> > > > of this element is to enable direct equivalence mappings between
> > > > identifiers
> > > > with no overloading of either: a) resolution semantics, or b)
> mapping
> > > > (replacement) semantics.
> > > >
> > > > To leave this element out of the base XRD namespace would be to
> invite
> > > > lots
> > > > of non-standard ways to express a very basic concept.
> > > >
> > > > > 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.
> > > >
> > > > I'm not sure who may have given the impression that EquivID could
> be
> > > used
> > > > to
> > > > provide directional equivalence; I've always said that its purpose
> was
> > > > non-directional, and that directional equivalence should use
> > > > MapToID/MapFromID. I agree with you that separate elements for
> > > > non-directional and directional equivalence is much more precise,
> and
> > > > makes
> > > > it easier for communities and applications to set policies around
> > > their
> > > > use
> > > > of these synonym types.
> > > >
> > > > =Drummond
> >