Re: Issue 192 & R803

Mark,

Mark Baker wrote:

>>Non-SOAP HTTP intermediaries have no business with the SOAP envelope
>>in the entity body except as an opaque blob that happens to be
>>of some media type. If they go beyond that, then IMO, they are
>>SOAP intermediaries.
>>
> 
> Absolutely!  That's why the HTTP envelope needs to be kept in synch
> with what SOAP is doing.


which is reflected in the HTTP binding, so I don't understand your
issue.


> 
> 
>>>I don't follow.  The processing model doesn't care whether the received
>>>envelope contains a fault or not.  This is consistent with the
>>>chameleon use.
>>>
>>
>>That's not how I read section 2.5. A SOAP intermediary isn't concerned
>>with the SOAP Body EII and its contents, to be sure, but the
>>SOAP node operating in the .../ultimateReceiver role MUST be capable
>>of "correctly processing" the contents of the SOAP Body EII which I
>>interpret as meaning, if the child of the SOAP Body EII is a SOAP
>>Fault EII, it is a fault, and I process it as such unless there
>>is some SOAP Header block telling me otherwise. That is the SOAP
>>processing model as I understand it. The SOAP Processing model
>>doesn't say anything about bells and whistles in the underlying
>>protocol effecting the SOAP processing of the received SOAP message.
>>
> 
> That's not how I interpret it, and your interpretation goes against the
> chameleon view and R803.  We should probably fix the wording if it's
> being interpreted in this manner, because surely you won't be the only
> one to interpret it this way.


I'll leave it to others to chime in on this aspect. I believe I have
seen others who agree with my interpretation.


> 
> 
>>You've lost me entirely.
>>
> 
> In order to understand a message, you have to understand the context in
> which the message is communicated.  In the chameleon view, the
> underlying protocol provides the outermost context.  In the tunnel view,
> the SOAP envelope does (i.e. it disregards the meaning of the
> containment of the SOAP envelope within the HTTP envelope).

> 
> 
>>>But an HTTP intermediary doesn't "process" the SOAP message; it knows
>>>nothing of SOAP.  But it does know about success and failure.
>>>
>>
>>Now I am completely at a loss to understand what your issue is.
>>
>>The resolution to issue #12 says that if a fault is generated,
>>as a result of SOAP processing, you use a non 2xx HTTP status
>>like 5xx or 4xx. That seems consistent with the chameleon view
>>in my mind, so I'm at a loss to understand what issue you might
>>have with that aspect.
>>
> 
> I'm happy with the resolution of issue 12.  It's having a consistent
> interpretation of the contra view that is what 192 is about.


What contra view? The edge case you've put forth? I don't buy it.

Unless the same semantic can be expressed within the encapsulated

SOAP envelope it isn't a portable semantic. As I've repeatedly
suggested, the SOAP Fault can be wrapped or have its semantic
interpretation modified by means of a SOAP Header extension
that says effectively, this SOAP Fault is not a Fault.


> 
> 
>>On the other hand, you say you have a use case where you want
>>the equivalent of GET /errors/404 HTTP/1.1 which returns a SOAP
>>message that is identical in all respects to a generated SOAP
>>Fault message, tack it onto an HTTP/1.1 200 OK response and
>>have it treated by the receiving SOAP node as <not><fault/></not>
>>(as well as by any non-SOAP intermediaries).
>>
>>What I'm saying is that you cannot do this consistently for
>>*all* transport/transfer mechanisms because they are not all
>>as perfect as HTTP. SOAP is intended to be independent of
>>any underlying transport/transfer mechanism used to convey
>>SOAP messages:
>>
> 
> Yes, and with the chameleon view, these things only come out in the
> binding.  SOAP and the binding framework would remain independant of
> any underlying protocol.


Then this chameleon view is non-interoperable use of SOAP with
other protocols that do not, or cannot convey this sort of OOB
information (w/r/t the SOAP envelope infoset) and that violates
R604 unless the information that is exclusively carried by the
underlying protocol is somehow capable of being expressed within
the SOAP message itself such as by means of the SOAP Header
extension I proposed in previous emails. You may think it
unnecessary overhead, but I do not.

I guess we'll just have to agree to disagree on this point.


> 
> 
>>A SOAP message carries its own semantics.
>>
> 
> Not in the chameleon view, it doesn't, as I explained above.  The
> context provided by the underlying application protocol is required
> in order to understand the entire message.
> 
> Sorry, I'm repeating myself, I know.  But I'm a bit confused.  Are you
> trying to say that the chameleon view is invalid, or just that my
> interpretation of it is incorrect?

> 
> I understand that this is difficult to communicate, because there's
> several important things that have gone unsaid in the work we've done
> here, not the least of which is that REST is a sufficient basis upon
> which to implement Web services.  REST doesn't need the tunnel view of
> SOAP, it just needs a protocol that implements the architecture it
> defines.  That is HTTP.  The chameleon view exposes REST through
> SOAP, by inheriting HTTP's application semantics.


I understand and appreciate your enthusiasm for REST and HTTP.
I do believe that there's significant merit there, I just don't
think that I necessarily share your view of REST/HTTP world
domination:)

In my mind, the chameleon view needs to be mutually respective of
each other's semantics. If a SOAP Fault message is NOT intended to
be interpreted as a SOAP Fault message in the HTTP 200 OK
sense, then (IMO) it MUST reflect that *within* the SOAP envelope
so that the semantic intent is not lost if/when the message crosses
over to another protocol domain, be it SMTP, FTP, TCP or whatever.

The resolution to issue #12 supports the chameleon view that
the 'fault' semantics be conveyed in the HTTP Status Response
Code in the SOAP HTTP binding. I honestly don't see why you can't
live with either the wrappering or the header block modifier
approach to resolve issue #192 so that the semantics of a SOAP
Fault are consistent for ALL bindings regardless of whether they
are application protocols or lowly transport protocols.

> 
> 
>>To a SOAP Processor, a
>>SOAP message with a SOAP Fault EII as the child EII of the SOAP Body
>>EII is a Fault, barring any SOAP Header extension that modifies these
>>semantics. If you want to convey the equivalent of carrying a 404
>>response entity body's HTML representation on an HTTP 200 OK, then
>>you need to have some equivalent in SOAP. The SOAP Header extension
>>example I gave in my previous posting would be an example of that.
>>There's just no escaping this IMO or else you've broken SOAP for
>>anyone not using HTTP protocol (exclusively) which defeats the
>>whole point of SOAP (IMO).
>>
>>To impose a requirement that all underlying transport/transfer
>>mechanisms to which SOAP is bound be capable of (natively)
>>conveying fault information the way HTTP does/can is unrealistic
>>and violates R600 above.
>>
> 
> Not just HTTP, but all application protocols.  Every application
> protocol I know of has a notion of "failure" and "success".  I'm saying
> that best practice for SOAP bindings to application protocols should be
> to use those as authoritative.
> 
> MB
>

Received on Friday, 29 March 2002 16:06:05 UTC