RE: "Uh, what do I need this for" (was RE: XML.COM: How I Learne d to Love daBomb)

[Michael Brennan <Michael_Brennan@allegis.com>]

> From: Simon St.Laurent [mailto:simonstl@simonstl.com]

<snip/>

> The IETF has a draft[1], but I'm not sure it's made it to Best Current
> Practices. (Last call went out 17 October 2000, so it may have been
> dropped.)  The more I've thought about this issue, the more I think
> Keith Moore is right.  XML-RPC is as far as I'm willing to push HTTP,
> and that may be reasonably considered to be too far.
> 
> [1] -
> http://search.ietf.org/internet-drafts/draft-moore-using-http-01.txt

This has been hashed and rehashed in other forums. The draft you reference
was never identified as being on a standards track, and it directly
conflicts with the HTTP RFC, which states:

   The Hypertext Transfer Protocol (HTTP) is an application-level
   protocol for distributed, collaborative, hypermedia information
   systems. It is a generic, stateless, protocol which can be used for
   many tasks beyond its use for hypertext, such as name servers and
   distributed object management systems, through extension of its
   request methods, error codes and headers [47].

Right or wrong, that's what the spec says. SOAP's use of HTTP is entirely
consistent with the guidance in the HTTP RFC. The draft you cite is quite
inconsistent with the RFC. It is also worth pointing out that SOAP can be
used with other protocols, such as BEEP (as you yourself pointed out in
another post), so there is nothing to stop implementors for pursuing more
robust protocols.

I hope BEEP succeeds. The use of HTTP, though, is driven by practical
considerations. The tools and infrastructure for HTTP support are
ubiquitous, and can be had at minimal cost (or even for free). Anything that
attempts to displace HTTP for XML messaging will have to provide similar
compelling attractions to developers or it has no hope of gaining mindshare.