[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri-editors] URI authority resolution
so, i agree with Gabe, in that equiv. statements are at the addressing layer, and we should use a term such as 'mapping' when discussing other xri's which point to the same representation. trustable mapping is performed via trusted resolution, which returns an assertion of equivalence... that is, an assertion that @Microsoft/(+website) is another name for the resource representation of http://www.microsoft.com/ or @!1!2!3/(+website) 'synonym' is as good a term as any i suppose, tho linguistically, synonyms tend to imply a more lax equivalence. --- peterd On Mon, 2004-11-29 at 15:35, Drummond Reed wrote: > Hmmm. I understand what you're saying about it not being a "trustable > statement of equivalence", but to me the issue of trust seems separate > from the issue of what this other XRI really is. It seems what these > XRIs represent is "another XRI for the resource represented by the XRI > being resolved". > > > > Is that right? > > > > If so, my first inclination would be to say that by definition that is > an equivalent XRI. However if that's too strong, because "equivalent > XRI" should mean character-for-character equivalent, then we should > pick a term for "two or more XRIs that represent the same logical > resource" and use that. > > > > In XDI we have been using "synonym". How would that work for you, > i.e., > > > > <Synonyms> > > <OtherAuthority>xxx</OtherAuthority> > > <OtherAuthority>xxx2</OtherAuthority> > > <SameAuthority>yyy</SameAuthority> > > <SameAuthority>yyy2</SameAuthority> > > </Synonyms> > > > > The other option would be to go even more generic and just call them > "other XRIs for this same resource", in which case it could look like: > > > > <OtherXRIs> > > <OtherAuthority>xxx</OtherAuthority> > > <OtherAuthority>xxx2</OtherAuthority> > > <SameAuthority>yyy</SameAuthority> > > <SameAuthority>yyy2</SameAuthority> > > </OtherXRIs> > > > > > > =Drummond > > > > > ______________________________________________________________________ > > From: Wachob, Gabe [mailto:gwachob@visa.com] > Sent: Monday, November 29, 2004 12:16 PM > To: Drummond Reed; xri-editors@lists.oasis-open.org > Subject: RE: [xri-editors] URI authority resolution > > > > > I don't like Equivalent because its not a statement of equivalence. At > least not a trustable statement of equivalence. > > > > > > These statements are NOT saying that xxx is *equivalent* to the > authority id being resolved, in the example I give. Consider the use > case where @Microsoft is being resolved into @!1!2!3 through the > <Mapping> mechanism I proposed... This is not a statement that > @Microsoft is *equivalent* to @!1!2!3, its a statement that @Microsoft > maps into (only for this point in time, and only to be trusted in the > direction of @Microsoft to @!1!2!3, not @!1!2!3). The word > "equivalence" is a much stronger assertion, I think, and one we should > avoid. Thats why I use the term "mapping"... > > > > > > I'm fine with something else besides mapping, but equivalence seems to > me to be problematical.. > > > > > > -Gabe > > > > > > __________________________________________________ > gwachob@visa.com > Chief Systems Architect > Technology Strategies and Standards > Visa International > Phone: +1.650.432.3696 Fax: +1.650.554.6817 > > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Monday, November 29, 2004 11:27 AM > To: xri-editors@lists.oasis-open.org > Subject: RE: [xri-editors] URI authority resolution > > On the XML naming point, I agree with you Gabe. I > intentionally chose these just to make the point that our > original names were not nearly clear enough. > > > > I like your two-level approach. However since I still feel > that "Mappings" is not clear enough, how about calling the > container "EquivalentXRIs", i.e.: > > > > <EquivalentXRIs> > > <OtherAuthority>xxx</OtherAuthority> > > <OtherAuthority>xxx2</OtherAuthority> > > <SameAuthority>yyy</SameAuthority> > > <SameAuthority>yyy2</SameAuthority> > > </EquivalentXRIs> > > > > =Drummond > > > > > ______________________________________________________________ > > From: Wachob, Gabe [mailto:gwachob@visa.com] > Sent: Monday, November 29, 2004 11:04 AM > To: Drummond Reed; xri-editors@lists.oasis-open.org > Subject: RE: [xri-editors] URI authority resolution > > > > > Just to be clear: "SameAuthorityEquivalentXRIs" will never be > resolved - its simply (as dave puts it), a hint about > optimizing cache performance, essentially (and may be made > available to applications for comparison purposes, for > example). Though, its not really a trustworthy assertion of > equivalence, since anybody can assert this sort of equivalence > (I can say I'm equivalent to the permanent ID that @Microsoft > resolves to - can my assertion really be trusted?) > > > > > > DifferentAuthorityEquivalentXRIs is saying "do also resolve > this XRI authority over there if you have any need to". This > XRI *will* get resolved, and is not really a cache hint or > application hint about equivalence. > > > > > > I'm happy with calling them Foo and Bar at this point. As long > as we're clear about semantics and processing rules (which are > clear to me - but I'm not entirely convinced that they'll be > easy to use given the trust issues). > > > > > > Oh - and I hate XML names with 4 different words > SmushedIntoOneSoItsClearToHumans... We should work harder to > find something a little less verbose.. > > > > > > One thing we might consider is > > > <Mappings> > > > <OtherAuthority>xxx</OtherAuthority> > > <OtherAuthority>xxx2</OtherAuthority> > > <SameAuthority>yyy</SameAuthority> > > > <SameAuthority>yyy2</SameAuthority> > > > </Mappings> > > > > > > Anyone see a problem with that? > > > > > > -Gabe > > > __________________________________________________ > gwachob@visa.com > Chief Systems Architect > Technology Strategies and Standards > Visa International > Phone: +1.650.432.3696 Fax: +1.650.554.6817 > > -----Original Message----- > From: Drummond Reed > [mailto:drummond.reed@cordance.net] > Sent: Friday, November 19, 2004 6:04 PM > To: xri-editors@lists.oasis-open.org > Subject: RE: [xri-editors] URI authority resolution > > Okay, Dave called me to explain, and now I really do > get it, but the difference is even more subtle. Here's > how it breaks out: > > > > Type #1 is the XRI being described by the current > XRID. > > Type #2 is any other XRI asserted in this XRID as > being equivalent to XRI #1 AND which resolves to this > same authority (and thus will return this same XRID.) > > Type #3 is any other XRI asserted in this XRID as > being equivalent to XRI #1 but which resolves to a > DIFFERENT authority and thus will return a different > XRID (because what it represents is another physical > instance of this logical resource). > > > > The difference in #2 and #3 is of course very > important, because essentially #2 is an XRI authority > saying "here are the aliases of XRI #1 that resolve to > me" and #3 is the same authority saying, "here are the > aliases of XRI #1 that resolve to anohter authority". > > > > If this is the case (tell me I've got it right, Dave), > then as I suspected the semantic issue gets much > easier. Rather than "Mapping" and "AlternativeXRI", > neither of which make that distinction clear, I think > what we need is something more like: > > > > <SameAuthorityEquivalentXRIs> > > <OtherAuthorityEquivalentXRIs> > > > > See what I mean? Pretty hard for that to be ambiguous. > > > > Thoughts? > > > > =Drummond > > > > > > > ______________________________________________________ > > From: Drummond Reed > [mailto:drummond.reed@cordance.net] > Sent: Friday, November 19, 2004 4:52 PM > To: xri-editors@lists.oasis-open.org > Subject: RE: [xri-editors] URI authority resolution > > > > > Sorry, I just got to this entire thread (been that > kind of week), and to Gabe's final question "Does > everyone understand this?", my answer is, "No." > > > > Well, in truth, I think I get it, but the very fact I > am having to study the thread so closely, and STILL > feel that the distinction between "Mapping" and > "AlternativeXRI" is not clear enough, is a signal this > needs more work. > > > > My suggestion is that we should stop thinking about > the tag names for the moment and first just get it > completely clear the logical difference, from a > resolution standpoint, between the three types of XRIs > being discussed. > > > > If we call them XRI #1, XRI #2, and XRI #3, is the > following correct? > > > > Type #1 is the XRI being described by the current > XRID. > > Type #2 is any other XRI asserted by the authority for > #1 as being equivalent to XRI #1. > > Type #3 is any other XRI asserted by the authority for > #1 as producing an equivalent XRID to this XRID. > > > > Is that the difference? In which case, how is #2 > really different from #3? Or are they just different > ways of making what is ultimately the same assertion? > (Those questions are for Gabe and Dave and Peter.) > > > > My sense is that once we can answer these questions > clearly, it will be much easier to decide on > appropriate semantics for the tag names. > > > > =Drummond > > > > > > > ______________________________________________________ > > From: Wachob, Gabe [mailto:gwachob@visa.com] > Sent: Thursday, November 18, 2004 2:52 PM > To: xri-editors@lists.oasis-open.org > Subject: RE: [xri-editors] URI authority resolution > > > > > Dave and I discussed this on the phone and we came up > with a sensible way of describing the functionality. > > > > > > Think of AlternativeXRI as "Include" and Mapping as > "AlsoKnownAs". > > > > > > The effect of Mapping is to give the resolver a hint > that the resolved authority is also known by another > authority ID. This assertion is only trusted one-way - > that is if xri://=Wachob contains a > <Mapping>xri://=!1!2</Mapping>, then the resolver may > cache (with some trust) the fact that if someone wants > xri://=Wachob, the XRID for xri://=!1!2 may be used > instead. The resolver should NOT, however, return the > XRID resulting from xri://=Wachob if someone asks > about xri://!1!2 . Mapping may also affect other > behavior (such as reporting back this Mapping to the > user of the resolver). The key thing with Mapping is > that the XRID that results from resolving the XRI in > the Mapping element shoudl be functionally equivalent > to the XRID in which the Mapping element is found. > > > > > > AlternativeXRI is, for me, the way I'd map an alias to > another XRI. Its effect on the resolver is to say > "Please look at the XRID for this identifier as well > as the XRID you are currently looking at". It is > therefore, in effect, saying "please go logically > include the XRID that comes from resolving XRI > Authority X" (where X is the content of the > <AlternativeXRI> element. The XRID resulting from > resolving the XRI in the AlternativeXRI is likely to > be very different than the XRID in which the > AlternativeXRI element is found. A resolver would > typically use the XRI in AlternativeXRI if it cannot > find the local access service or authority URI it > needs in the current XRID. > > > > > > I'd actually suggest that we rename <AlternativeXRI> > to <Include> (or <Import>?) . I think Mapping > describes its function well and doesn't really need to > be changed. Since AlternativeXRI hasn't yet been > written into the 1.0 spec, this shouldn't be a real > "change" except as from the errata (which was never > formally adopted anyway). > > > > > > Does everyone understand this? > > > > > > -Gabe > > > > > > __________________________________________________ > gwachob@visa.com > Chief Systems Architect > Technology Strategies and Standards > Visa International > Phone: +1.650.432.3696 Fax: +1.650.554.6817 > > -----Original Message----- > From: Wachob, Gabe [mailto:gwachob@visa.com] > Sent: Thursday, November 18, 2004 1:18 PM > To: Dave McAlpin; Davis, Peter > Cc: xri-editors@lists.oasis-open.org > Subject: RE: [xri-editors] URI authority > resolution > > I'll want to discuss this more, as I want to > be crystal clear to implementers what they > should be doing when they receive one or more > of these elements. For example, is there a > requirement that one be used (ie > AlternativeXRI) over the other (Mapping) if > they both appear? Should they only be > consulted if there is no appropriate local > access available? > > > > > > As to trusted resolution - one issue I see is > that if an XRID contains a "Mapping" element, > is there not an assertion of equality between > the authority identified by the resolved > authority ID and the authority ID in the > mapping element? If thats the case, what can > the resolver "trust" about this resolution? > For example, if the Mapping contains the XRI > xri://@!1!3!4, can the XRID containing the > mapping element be used (in a *trusted* > fashion) for xri://@!1!3!4 without having to > actually resolve xri://@!1!3!4? If not, then > why is this a Mapping and not an > AlternativeXRI? Can Mapping ever really be > used in a trusted resolution? > > > > > > -Gabe > > > __________________________________________________ > gwachob@visa.com > Chief Systems Architect > Technology Strategies and Standards > Visa International > Phone: +1.650.432.3696 Fax: +1.650.554.6817 > > > -----Original Message----- > From: Dave McAlpin > [mailto:Dave.McAlpin@epok.net] > Sent: Thursday, November 18, 2004 6:51 > AM > To: Davis, Peter; Wachob, Gabe > Cc: xri-editors@lists.oasis-open.org > Subject: RE: [xri-editors] URI > authority resolution > > Right. I assumed the XRI would be > something like > xri://xri.wachob.com/foo, where > xri.wachob.com was just responsible > for answering XRI requests. If that > seems too burdensome, I'd be fine with > something like xri://wachob.com/foo > converting to > http://wachob.com/XRIDescriptor.xml. > The main thing I'm looking for is > consistent resolution for both XRI > authorities and URI authorities. > > > > > > Dave > > > > > > ______________________________________ > > From: Davis, Peter > [mailto:peter.davis@neustar.biz] > Sent: Thu 11/18/2004 7:10 AM > To: Wachob, Gabe > Cc: xri-editors@lists.oasis-open.org > Subject: Re: [xri-editors] URI > authority resolution > > > hmm... this would require careful > consideration of a unique webserver > deployment, and preclude authorities > (such as 'personal' ones) from > legitimately offering and XRIAuthority > of xri://peterd.us/xri > > In your example, it is more than > likely that http://wachob.com also > service html content. presently, the > HTTP resolve request does not > convey 'what' it is asking for... we > simply expect that an authority > publishes an address which only > services resolve requests... something > http://wachob.com may not (want to) > do. > > maybe this is a non-issue, if the user > opts to express their authority > as an HTTP URI? > > just a thought. > > --- peterd > > On Wed, 2004-11-17 at 19:20, Wachob, > Gabe wrote: > > Dave McAlpin had suggested we want > to come up with a better method for > > resolution for XRIs with URI > authorities (ie DNS or IP addresses) > than > > the current method of converting the > XRI into a HTTP URL and > > performing the HTTP protocol on the > new HTTP URI. > > > > I do not believe we have discussed > an alternative resolution > > mechanism, so here's my proposal: > > > > 1) Take the authority identifier (an > IP address or DNS name) and > > construct a HTTP URI that consists > of "http://"; + the dns name or IP > > address. > > > > 2) Perform an HTTP GET on the > resulting HTTP URL > > > > 3) The result of the HTTP GET will > be a XRIDescriptor as would > > normally be returned per XRI > Authority resolution, possibly signed. > > > > For example, resolving the authority > for xri://wachob.com/foo would > > cause a HTTP GET to > http://wachob.com which would result > in the XRID > > for xri://wachob.com > > > > ---------------- > > > > An enhancement to consider would be > the use of SRV records (when > > available) when a DNS name is used. > The publication of an SRV record > > would be optional, but would allow > more flexibility on the part of the > > authority. The process would then > be: > > > > 1) Take the authority identifier > which is a DNS name. (if an IP > > address, then use the above > algorithm) > > > > 2) Add _xria._http._tcp to the front > of the DNS name (as per SRV spec > > - RFC 2782 > http://zvon.org/tmRFC/RFC2782/Output/index.html) > > > > 3) The resulting domain name and > port number (from the resulting SRV > > record) would be used to construct a > HTTP URL. Note that the domain > > name could be "xri-specific" > allowing use of a generic domain name > in > > the XRI, but resulting in a HTTP > request (step 4) to a XRI-authority > > specific URL. If the SRV record > doesn't exist, then just construct the > > HTTP URL as in the above algorithm. > > > > 4) Perform an HTTP GET on the > resulting HTTP URL (constructed from > the > > SRV resolution) > > > > 5) The result of the HTTP GET will > be a XRIDescriptor as would > > normally be returned per XRI > Authority resolution, possibly signed. > > > > So, for example, resolving the > authority for xri://wachob.com/foo > > would be cause the following steps: > > > > 1) Resolve > _xria._http._tcp.wachob.com SRV > record, resulting in host > > xri-auth.wachob.com port 80 > > > > 2) Perform HTTP GET to > xri-auth.wachob.com on port 80 which > would > > result in the XRID for > xri://wachob.com > > > > ----- > > > > Please let me know what people think > about these proposals and whether > > they are worth the effort to include > in the resolution specification. > > > > -Gabe > > > > > __________________________________________________ > > gwachob@visa.com > > Chief Systems Architect > > Technology Strategies and Standards > > Visa International > > Phone: +1.650.432.3696 Fax: > +1.650.554.6817 > > > > > > To unsubscribe from this mailing > list (and be removed from the roster > > of the OASIS TC), go to > > > http://www.oasis-open.org/apps/org/workgroup/xri-editors/members/leave_workgroup.php. > > > > > To unsubscribe from this mailing list > (and be removed from the roster of the > OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/xri-editors/members/leave_workgroup.php. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]