Issue 93.pptVIP

Issue 93 Mu at Client (mustUnderstand on client side) Paul Kulchenko asked: Hi, All! Since its 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. Client Behavior 3 Choices Ignore it As Henrik pointed out this is definitely wrong – spec says it can not be ignored Fault back to the server Fault back to the client Mark Nottingham noted that it will probably be application dependent (so either 2 or 3) 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 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: Identify all blocks of the XMLP/SOAP message intended for that application (see section 4.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. 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. Two Issues What does the Spec say about Faults? Client behavior 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 (?) Client Behavior 3 Choices Ignore it As Henrik pointed out this is de