Re: XML Protocol: Proposals to address SOAPAction header

>> It is important that the SOAPAction URI be preserved between gateways.

SOAPAction relates to SOAP over **HTTP** - why should a different binding to
forced to carry it when it certainly is not needed by this other binding?

I think SOAPAction over HTTP should be dropped for reasons other people have
already explained on this list, but what ever decision is taken on that it
surely should not impact other bindings.

There is a SOAP over BEEP binding proposal coming out soon and it carries
the SOAP envelope only - not the SOAPAction **HTTP** header. BEEP has no
need for such a header - as the BEEP profile will unambiguously state that
it is carrying SOAP envelopes.

To turn the argument around, if it is fair for binding A to force binding B
to carry information specific to binding A, then surely the reverse is also
fair. So will the HTTP binding be capable of carrying the BEEP ansno, if
desired? (Someone might ask what is ansno, which proves the point - you
don't know what other bindings might wish to have carried. For the curious,
ansno is used for Request/N-Responses - which is one of a number of native
BEEP message exchange styles).

People need to clearly understand that SOAP will be carried over many
application protocols - and the whole idea of clean layering is to separate
what should go into SOAP itself (content and semantics of the SOAP envelope)
from how that envelope gets transported from A to B to C (the binding to the
underlying application protocol[s]).

Received on Monday, 11 June 2001 14:31:33 UTC