RE: [xri] Resolution Simplification

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

Nat-

    Great questions. Let me also address your question about the XML-as-query.

   

    First of all, yes, several HTTP requests are made to several hosts, and you ask about letting the first host do some sort of "recursive" resolutoin out of a cache (ie have a resolver provide the entire resolution to a client). I actually had a discussion with dave mcalpin that briefly touched on this, and my feeling is that this would be a common way to deploy resolution, and maybe it can be specified by us, but its not specified yet. Because of delegation, there will always be multiple HTTP requests - but the idea is that these requests are *cacheable* - thats one of the main reasons for relying directly on HTTP.

 

    As for using someting beyond GET (ie POST), the motivation here is to promote cacheability. POST requests generally *aren't* cacheable, but GET requests on URIs that are common between different resolutions *can* be cached succesfully.

 

    I think its entirely reasonable to think of a more generic resolutoin process based on explicit XML queries (e.g. in POST messages) and multiple transports. In other words,something like a SOAP infrastructure for resolution. I was trying to do something simpler and easier to develop. I think deploying such an infrastructure might be entirely possible - in the sense that what is described in my proposal could easily be "cast up" into richer semantics. I'm trying to do the "simplest thing that could possibly work", and I don't see the need for full XML queries. I think it may actually not be so complicated to think about a more complex query which includes XML content, but I don't think we should specify that right now because I don't see requirements for it and it complicates the caching story quite a bit.

 

    The issue about getting HTTP through firewalls is legitimate, but I would note that a) there's nothing wrong with performing resolution through a proxy (and a cache) and b) I think it should easy to deploy gateways - such as an smtp gateway. I believe HTTP is a relatively special protocol in the sense that its available in the vast majority of corporate networks. DNS is less so - some networks don't provide access to DNS at all - and only allow web access through a proxy (and only the proxy has access to DNS).

 

    I'm glad you have a positive response to the simplification, in general. I'm hoping that I'm addressing your concerns. I think what you propose could be useful in some situations, but what I'm trying to do now is get out something that would work for as many things as possible and be easy to implement. I'm still positioning this proposal as *a* resolution process for XRIs, not *the* process.

 

    I'd also point out that part of my focus on HTTP is a belief that HTTP is very much a generic "application protocol" and not just a "transport protocol". That is, the verbs GET/POST/PUT/DELETE are actually quite generic and usable in ways which most folks aren't familiar with - in particular the REST architecture is quite compelling for widely distributed interactions. http://internet.conveyor.com/RESTwiki/moin.cgi/FrontPage

   

    -Gabe

-----Original Message-----
From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp]
Sent: Wednesday, September 03, 2003 7:24 PM
To: Wachob, Gabe; xri@lists.oasis-open.org
Subject: RE: [xri] Resolution Simplification

I always have been a pusher for the simplification, especially for writing things in terms of HTTP (since last fall). DDDS was much too complex, and required too much knowledge on behalf of the readers.

 

There is couple of things to think about though:

 

(1)     This proposal calls for at least several HTTP communications to potentially different host. This is a rather expensive operation. What would be the down side for letting the first contact server try to resolve the authority section in its entirety from the cache? (Non-authoritative answer).

(2)     In Gabe’s proposal, GET is used, but what about using POST? This allows more complex data to be sent from the client for query. For example, sending XML formatted request. This allows the extensibility as well as setting many options. It can incorporate the signature from the client as well. It is going to be a good hook for the security extension as well. More over, we may be able to make the resolution just another web service: same as other XNS services. This is better from the point of view of symmetry. Also, it is going to be less cryptic for the reader. This is a big gain.

 

Cheers,

 

Nat

 

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Thursday, September 04, 2003 3:26 AM
To: 'xri@lists.oasis-open.org'
Subject: [xri] Resolution Simplification

 

XRI Members-

    Its become rather clear to me that one of the impediments to getting feedback on the XRI spec is the density of the Resolution section and its reliance on DNS technologies thats folks are very unfamiliar with (e.g. DDDS).

 

    Towards the goal of getting XRI traction, I'm proposing a much simpler resolution process that focuses almost entirely on HTTP rather than trying to provide a framework for pluggable resolution. This proposal is 6 pages long (rather than the current 15-16 pages). No flowcharts!

 

    I've spoken with Dave McAlpin and we've got a pretty clear path for doing secure resolution with it as well. My proposal doesn't lay out those details, but rather suggests where the hooks are for doing secure resolution.

 

    I'm pretty confident that this simplification is a great step forward as it makes resolution a much more conventional process that relies more directly on HTTP.

 

    Please see the attached document and send feedback to the list or to myself. No decision has been made (obviously), but I'm hoping this proposal gets a general initial thumbs up. Its certainly a lot more understandable. Section 3.1 of the -07 draft is largely still applicable - so it might be useful to read that before you read this proposal.

 

    -Gabe