1. Issue 93 Mu at Client (mustUnderstand on client side) Doug Davis XMLP F2F June 2001

2. Paul Kulchenko asked: Hi, All! Since it's possible to return a Header from server to client also, what should the client do if this header has mustUnderstand attribute or wrong actor? Best wishes, Paul.

3. Client Behavior 3 Choices 1.Ignore it As Henrik pointed out this is definitely wrong – spec says it can not be ignored 2.Fault back to the server 3.Fault back to the client Mark Nottingham noted that it will probably be application dependent (so either 2 or 3)

4. Proposal Basically, leave it as is… The processing model must not be ignored –Use this specific case in an example and state that a Fault must be generated but how the application chooses to act on it is up to the implementation Clarify the Spec to clearly state that, except for the server side of the RPC case, where faults are sent is an implementation detail or application specific

5. Processing Model A XMLP/SOAP application receiving a XMLP/SOAP message MUST process that message by performing the following actions in the order listed below: 1.Identify all blocks of the XMLP/SOAP message intended for that application (see section 4.2.2)section 4.2.2 2.Verify that all mandatory blocks identified in step 1 are supported by the application for this message (see section 4.2.3) and process them accordingly. If this is not the case then discard the message (see section 4.4). The processor MAY ignore optional blocks identified in step 1 without affecting the outcome of the processing.step 1section 4.2.3section 4.4 3.If the XMLP/SOAP application is not the ultimate destination of the message then remove all blocks identified in step 1 before forwarding the message.step 1

6. Two Issues 1.What does the Spec say about Faults? 2.Client behavior

7. Spec on Faults In the RPC case the Spec implies that server generated Faults should be sent back to the client The Spec is silent on what to do with Faults in all other uses of SOAP (non-RPC) –Implementation specific detail (?)

8. Client Behavior 3 Choices 1.Ignore it As Henrik pointed out this is definitely wrong – spec says it can not be ignored 2.Fault back to the server 3.Fault back to the client Mark Nottingham noted that it will probably be application dependent (so either 2 or 3)

9. Client Behavior Spec should clearly state what to do –Dick Brooks: …I would have to say it is important to specify client side behavior with regards to processing SOAP headers within response messages.

10. Server Behavior Server was stupid to send it in the first place –Noah Mendelsohn:…nobody is forcing the responder to use mustUnderstand headers in situations where they are going to cause trouble But, what about correlation Ids?

11. 3 rd Issue? Implementation Detail Does noticing the fault but choosing to do nothing with it violate the Spec? –Is this the same thing as ignoring it? –Must there be some change in semantics as a result of the fault?

13. Proposal Basically, leave it as is… Clarify the Spec to clearly state that, except for the server side of the RPC case, where faults are sent is an implementation detail or application specific The processing model must not be ignored –Use this specific case in an example and state that a Fault must be generated but how the application chooses to act on it is up to the implementation Clarify the Processing Model –Replace “discard the message “ with “generate a fault”