Issue 93

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
• 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)

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
• 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.

6
Two Issues

• What does the Spec say about Faults?
• 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
• 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)

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 Mendelsohnnobody is forcing the responder
  to use mustUnderstand headers in situations where
  they are going to cause trouble
• But, what about correlation Ids?

11
3rd 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?

12
(No Transcript)
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