RE: [xri] Proxy resolver nightmares

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

Victor,

First, I just want to second Wil's explanation that the reason for the
"xri." rule is to make HXRIs parseable by spiders and bots and other machine
processors that want to know that an HTTP URI is actually a proxy XRI. Wil's
right that you can run a proxy resolver at any HTTP URI, but unless the
domain starts with "xri." and the QXRI is the entire path, a machine won't
know that the HXRIs written to resolve from your proxy resolver are HXRIs.

On the second point, there was one pressing reason we had, in my opinion, no
choice to define an "HTTP interface" to XRI resolution: proxy resolution is
essential to backwards compatability of XRIs with HTTP infrastructure.

That's what the last 10 months have been all about.

=Drummond 

-----Original Message-----
From: Tan, William [mailto:William.Tan@neustar.biz] 
Sent: Tuesday, February 28, 2006 4:33 AM
To: xri@lists.oasis-open.org
Subject: RE: [xri] Proxy resolver nightmares

Victor,

I think the point of the "xri." -prefix convention is not a restriction.
It is intended for an application to be able to recognize XRIs embedded
in HTTP URIs (that are published in that form for the sake of
compatibility with non-XRI aware apps). Your
"fo.ob.ar/quirky/path/to/my/proxy/@bipolar*express" HXRI
is still accessible by non-XRI aware clients of course, and you can
certainly publish the proxy URI to XRI resolvers, and it's not breaking
any rule. It just means that my XRI search engine cannot harvest it off
the web easily. Though I do have some reservations towards creating
conventions like these, it doesn't pose any real harm and may encourage
adoption.

I tend to agree with you on sticking to only clients and resolution
servers in XRI resolution doc, but I'm afraid you're right that it's a
little late (Les & I had already given up resisting.)

BTW, Will you be joining the special TC call this afternoon 4pm PT?

=wil (http://xri.net/=wil)
 
 

> -----Original Message-----
> From: Victor Grey [mailto:victor@idcommons.org]
> Sent: Tuesday, February 28, 2006 11:05 PM
> To: xri@lists.oasis-open.org
> Subject: [xri] Proxy resolver nightmares
> 
> Sorry if I'm bringing this up a little late in the game, but I'm just
> waking up to the fact that I think the TC is going down a wrong road.
> It started with my rereading section 7.2 of WD10, namely:
> 
> "To make this syntax as simple as possible for XRI-aware processors or
> search agents to  recognize, an HXRI consists of a fully qualified
HTTP
> or HTTPS URI authority segment that  begins with the domain name
> "xri.". The query XRI (QXRI) is then appended as the entire local
path
> (and query component, if present.) In essence, the proxy resolver URI
> including the  terminating forward slash serves as a machine-readable
> prefix for an absolute XRI. "
> 
> I can see no reason for this draconian restriction. If I want to
> register the URI domain ob in Argentina, and set up a proxy resolver
at
> "fo.ob.ar/quirky/path/to/my/proxy/" so that I can respond to
resolution
> requests like "fo.ob.ar/quirky/path/to/my/proxy/@bipolar*express" --
> then why the heck not? It still conforms to the principle that the
QXRI
>   is appended to the entire proxy resolver address including the
> terminating slash. The only real requirement is that a proxy resolver
> address has a terminating slash, after which everything else is
> understood to be a QXRI.
> 
> But that led me (at 3 am) to the thought that proxy resolution is just
> a web service API, and that the XRI resolution document should not be
> considering web service APIs. XRI resolution concerns two entity
types,
> XRI authority servers, and their clients, AKA resolvers. The
resolution
> document should contain guidance and specifications for building those
> two types of entities, and that's all (that's enough!). WD9 had a lot
> more clarity in this regard, and I'm really worried that we are making
> a step backward.
> 
> If we, as a TC, want to get into the business of designing a web
> service API, then I'm am beginning to strongly feel that that should
be
> in a --separate proxy resolver document--, and not hold up the
> completion of the XRI 2.0 resolution document. Personally I feel that
> web services are better designed further downstream, and that those
> specs would be better relegated to XDI.org or other developer
> communities.
> 
> My $.02
> 
> =vg
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php