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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri-editors message

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


Subject: Closing on the XRID tag name issue


Title: Re: [xri-editors] URI authority resolution

I've renamed this thread to bring it back on track to help Gabe and Dave close on the question, "How should we resolve the issue of clarifying the 'Mapping" and 'AlternativeXRI' tag names?"

 

After discussing this with DaveM last night and looking at it again below, I propose applying the "KISS" principle and using the really simple tag names "OtherXRIs" for the container, and "SameAuthority" and "OtherAuthority" inside the container.

 

<OtherXRIs>

    <SameAuthority>yyy</SameAuthority>

    <SameAuthority>yyy2</SameAuthority>

    <OtherAuthority>xxx</OtherAuthority>

    <OtherAuthority>xxx2</OtherAuthority>

</OtherXRIs>

 

Other proposals? Votes?

 

=Drummond

 


From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Monday, November 29, 2004 12:36 PM
To: xri-editors@lists.oasis-open.org
Subject: RE: [xri-editors] URI authority resolution

 

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]