RE: [xri] Resolution Simplification

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:]
Sent: Wednesday, September 03, 2003 
  7:24 PM
To: Wachob, Gabe; 
  
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:] 
Sent: Thursday, 
  September 04, 2003 3:26 
  AM
To: 
  ''
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