Re: [xml-dev] HTTPEctomy considered bad (was RE: RE: [xml-dev] MS thinks HTTP Needs Replacing???)

[Paul Prescod <paul@prescod.net>]

Bill de hÓra wrote:
> 
> 
> >  
> > But HTTP is not a transport protocol (though you can use it 
> > that way). It is an application protocol, with a set of 
> > generic semantics. 
>
> No doubt. You will see the HTTP/SMTP-TCP/IP layers flattened in the
> future for better or worse. 

I don't believe that, but we'll see.

> ... A transport is somewhat relative. As
> Sean points out that has consequences if you expect messaging
> behaviour to remain consistent across what can be characterized as
> "transport soup". From the application's standpoint what it really
> wants are service or policy guarantees for message sending; how
> that is realised isn't that interesting to it. 

TCP is the layer that gives policy guarantees for message sending. It's
the *transport*. HTTP is the layer that adds application semantics. If
the application doesn't care about those semantics then it gets no
benefit from HTTP other than firewall avoidance.

> ....
> I'm not sure about this. Future network protocols will ideally
> concentrate on creating languages to articulate messaging policy
> and quality of service guarantees. An application can be remain
> agnostic if it can express its requirements to another service.

Applications can choose not to care how bits move from place to place.
But they cannot ignore the question of where the bits live, under what
names. That's what application protocols like HTTP and SMTP are about.

> All HTTP methods can be subsumed by SEND and RECEIVE, I don't care
> to argue whether that's desirable. 

What does "subsumed by" mean? Any protocol can be represented as
outgoing bits and incoming bits.

> ... And I'm wary of absolutism; "the
> end of science", "there's nothing left to patent" type utterances
> about HTTP and REST (or any computing item) don't convince me as
> rhetoric. 

I don't think that anybody claimed that we're at the end of science.
HTTP is a starting point, not and ending point. The problem is that
start with what we've learned from HTTP. It starts from scratch
reinventing a layer *below* HTTP.

> ... The issue with abstracting over HTTP is more strategic
> than technological: if you pull that abstraction off, you
> commoditize web infrastructure. Not at all unlike, say, the way
> hardware makers were commoditized by proprietary operating systems.

I don't understand what you are saying. It sounds interesting but I
don't understand it. How does SOAP "commoditize web infrastructure." How
much more "commoditized" could web infrastructure become? You can buy it
by the inch already.

 Paul Prescod