David,
When the CPA's AckRequested attribute has the value "perMessage," it
has been agreed that (1) whatever the sender indicates in the
message is to be honored and (2) no "Inconsistent" error check
is needed. That means that if a sender includes the Header element
requesting Acks, then the receiver is to return the Ack.
If the sender omits the indication that an Ack is desired, act
accordingly, and don't send the Ack.
Don't change the semantics of "perMessage" please!
We have struggled for some time to arrive
at a way to enforce agreed upon values (using the CPA)
and also to have an agreement that lets the Header values
alone determine behavior. Why mess with this now?
Dale
PS:
Also, as Arvola has indicated, the other two values that
the CPA uses are now "always" and "never". For the
AckRequested attribute, the "always" value means the
receiver has agreed to always acknowledge what the
sender sent, for the governing ServiceBinding and PartyIds.
If the Header element requesting an Ack is ever
missing, for that Service and PartyId,
an error is thrown. The receiver just does not
silently send the unrequested Ack.
The "never" value means never ack it, and if a sender
asks for an Ack, an error is thrown back; otherwise,
it sends no Ack back, just as "asked."