RE: [xri-editors] URI authority resolution

["Wachob, Gabe" <gwachob@visa.com>]

Title: 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.