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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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


Subject: 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


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