Re: another approach to status codes, etc. in HTTP binding

 Hello all. 8-)
 I apologize if I repeat somebody but I didn't read the whole
bulk of the discussion this time.
 My view on 2xx/4xx/5xx is the following:
 We've heard that SOAP is either an extension of HTTP or a layer
above HTTP.
 We've heard that HTTP is an application protocol, not a
transport protocol.
 Every application protocol can be "abused" to serve as a
transport protocol.
 Now we have XMLP. I'll use this acronym because I think we
should consider what we would do if we built XMLP from scratch,
and then compare it with what SOAP does and decide on the
relative merits. What I say about XMLP may not be true about SOAP
Version 1.2, I'm changing the facts here for the sake of
discussion.
 XMLP messages are defined in terms of Infoset, with processing
rules based on the Abstract Model. We need to transport the
messages from one XMLP node to another. We are in need of a
transport protocol. TCP will suffice for some applications.
 I guess nobody will argue that TCP is an application protocol.
 Now we see HTTP, and we know HTTP is good. And we know HTTP
traverses firewalls. And we decide to use HTTP.
 We use HTTP as a transport protocol because we need nothing more
from it than from TCP. This is a layered approach so XMLP faults
are HTTP successes.
 I can't see any reason why anybody would want to switch from 2xx
to 4xx/5xx in the scenario described above (_after_ having TCP
transport).
 Now back to reality - we have SOAP/1.1 and a working draft of
SOAP Version 1.2 and we started with the HTTP binding modeled as
an extension of HTTP. We are considering binding to TCP now.
 I can see how one binding could be layered over one protocol
while an other binding would extend an other protocol, even though
it is a bit of inconsistency.
 Anyway, does modeling the HTTP binding as an extension of HTTP
bring some significant added value? Will then the TCP binding
actually create a whole 'nother application protocol?
 So to conclude - I'm advocating the layered approach - use 2xx
for faults, and all that.
 Best regards,

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/




On Wed, 18 Jul 2001, Mark Nottingham wrote:

 >
 > > In other words, I think we should allow SOAP applications to use HTTP
 > > with all the bells and whistles that HTTP provides including using all
 > > status codes and header fields. In other words, let HTTP be HTTP :)
 >
 > What I'm hearing, then, is that the HTTP binding (and bindings in
 > general) should be expansive; e.g.,
 >
 > * SOAP envelopes can be encapsulated in request messages which have a
 >   method which permits an entity body (i.e., POST, PUT)
 >
 > * SOAP envelopes can be encapsulated in response messsages which have
 >   a status code which permits an entity body (i.e., 200, 400, 500,
 >   etc.)
 >
 > Thinking aloud, I'd be happy to take this approach *from a
 > theoretical standpoint* (more about that later) if we specify that
 > transport-related underlying protocol mechanisms (e.g., method,
 > status code, etc.) have no effect on how the SOAP message is
 > processed; i.e, their semantics are used to get the HTTP message (in
 > this case) around, not to hint or affect SOAP processing.
 >
 > This is because if there were a relationship between protocol
 > mechanisms and message processing, there would need to be a mapping
 > between them, and this could get ugly quickly.
 >
 > The upshot of this is that the HTTP binding wouldn't specify ANY
 > methods or status codes to use (except for the constraints as above),
 > but merely reference the specification.  The onus is on
 > implementations to assure that they can handle any messages sent
 > their way by a particular binding.
 >
 > This is a fairly radical change to specifying particular status
 > codes for particular SOAP messages, but I'm warming to it.
 >
 > Thoughts?
 >
 >
 >

Received on Thursday, 19 July 2001 13:42:09 UTC