Re: [xri] Proxy resolver nightmares

[Victor Grey <victor@idcommons.org>]

Tan, William wrote:
> I think the point of the "xri." -prefix convention is not a 
> restriction.
Really? From WD10:

1020  The normative ABNF for an HXRI is defined below based on the XRI 
and ireg-name
1021  productions defined in [XRISyntax]:
1022  HXRI  = proxy-resolver "/" QXRI
1023  proxy-resolver  = ( "http://"; / "https://"; ) proxy-reg-name
1024  proxy-reg-name  = "xri." ireg-name
1025  QXRI = XRI

> I tend to agree with you on sticking to only clients and resolution
> servers in XRI resolution doc,
I was at a conference where there was a representative from Liberty, 
who ruefully admitted that while SAML 2.0 "really wasn't that 
difficult" there was little chance of adoption by independent 
developers, because the specs were so impenetrable.

I don't want to see us go down that road.

Gabe expressed some concern lately that WD10 had lost some of the 
clarity around describing the actual resolution process, and I've been 
worrying about the same thing. I just woke up to the fact that the 
reason for this is the munging together of resolution and proxy web 
service.

Besides clarity, there are other good reasons not to mix these two 
subjects together. XRI resolution needs to be nailed down so that the 
early adopters can start building XRI authority servers and clients. 
Once there are a few of these around, and we are able to test our 
clients against each other's servers, we will have a much better idea 
of what the actual requirements for a proxy resolver are.

We are, imho, over-determining the proxy resolver design right now, as 
well as spending way too much time on it. Once we have a few good 
resolver client libraries available (I plan to release one as a Ruby on 
Rails plugin), we make it possible for web service developers to start 
creating a whole ecosystem of proxy resolvers, and this is desirable, 
yes?

But we don't know what their needs are yet. We do know that they will 
need a proxy service API spec that they can read and comprehend, based 
on the premise that they have a client available that can resolve an 
XRI and return a complete XRDS. The web service developer's job then, 
will be to parse the XRDS and implement the proxy API, a type of 
process web service developers are familiar with (for instance with 
RSS). Let's let that API be evolvable and informed by some real world 
experience.

> but I'm afraid you're right that it's a
> little late (Les & I had already given up resisting.)
Better late than never. Start resisting again  ;-)


> BTW, Will you be joining the special TC call this afternoon 4pm PT?
I will try.

=vg