I have some embedded comments related to Section 126.96.36.199 in
the 1.08 draft.
An ErrorList element can be included
in a SOAP Header that is part of a message being sent as a result of
processing of an earlier message.
In this case, the values for the Service and Action elements are set by the
designer of the Service.
We should make it clear that an
ErrorList element can be piggybacked on a business response message only if
the highestSeverity is not Error. Otherwise, a separate Error message must be
used. (This rule derives from section 5.1.4 which states that an ErrorList
with Error as highestSeverity cannot be present with a Manifest
<df>I'm kind of opposed to having Error messages
piggyback on some other message. Maybe we should take another look
An ErrorList element can also be
included in an SOAP Header that is not being sent as
a result of the processing of an earlier message. In this case, if the highestSeverity is set to
Error, the values of the Service and Action elements MUST be set as
The Service element MUST be set to: uri:www.oasis-open.org/messageService/
The Action element MUST be set to MessageError.
If the highestSeverity is set to Warning, the Service and
Action elements MUST NOT
<df>Where did this line come
from? Right, Service and Action are not optional. Maybe this means
these values must not be used? What if the Error message with a Warning
is sent back on its own? What would the Service and Action be? I
think this sentence needs to go.</df>
The Service and Action elements are not
optional. What should they be set to in this case? Are you suggesting that
piggybacking on a response message is mandatory if the highestSeverity is not
It may also be useful to add another
subsection parallel to 188.8.131.52 to identify the delivery channel that should be
used for sending Error messages. If the incoming message that is in error asks
for a synchronous reply, then the Error message should be returned
synchronously. Otherwise, the CPA should be consulted to determine the
appropriate delivery channel for a standalone Error message. This delivery
channel must not specify the use of reliable messaging because Error messages
must not be acknowledged.
<df>We need to talk
about this. I think Errors should be sent synchronously whenever using
HTTP regardless of the value of