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

-1

IMHO, this "loose" specification approach will lead to all manner of 
interop problems. 

Cheers,

Chris

A loose specification leads to even looser interpretation
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?
> 
> --
> Mark Nottingham, Research Scientist
> Akamai Technologies (San Mateo, CA USA)