[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]