treatment of aborted out-of-order seq

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: treatment of aborted out-of-order seq

We talked about two Issues that are not unrelated,
yet after review, I believe only one remains:

----- Issue 1:

Should the Receiver warn the Sender that an out-of-order sequence has been
aborted on the Receiver side, due to a reason other than message expiration?
(in case of message expiration, the Sender can - generally - deduce the failure).

Position 1: This can't be more than just an optimization, as the reliability
contract would not be broken anyway (would not cause delivery of un-ordered messages !)
And also we never rely on error messages for critical RM logic.
Note also that any further "quantitative" aspect of RM (e.g. about max length of
out-of-order sequence) is out of scope for V1 (line 103, sec 1.2)

Position 2: This is more than just an optimization, as it is a special failure case
with potential high cost if not dealt with as efficiently as possible:
without knowledge that a sequence has been given-up, cumulative and useless
resending (and new sending) may overwhelm the Receiver.
We fault individual messages for various reasons, including lack of storage resource,
so why not fault such a multi-message failure?

Opinion: In case a Poll request is used by the sender, it does not cost much to give
notice of the failure (see example in Issue #2 below) in the poll response.
So even if we see this notification as no more than an "improvement" (Position #1)
we can fault the dropped messages in the response.
But when callback is possible - and requested - should the Receiver send:
(a)- nothing at all
(b)- a special PermanentProcessingFailure for the entire group (so will that look like responses we do
for "singleton" groups?)
(c)- a PermanentProcessingFailure for each dropped message.
I personally favor (b) as a consistent complement to my opinion in poll request
case. A MAY or a MUST? I think again its just an optimization, so a MAY is OK.

----- Issue 2:

When we talk of generating Faults, and how to get them to Sender in case neither
callback or response pattern is possible. In that case, Polling is the only way a
Sender can get faults generated on Receiver.

Well, it appears that the Poll response can actually give the fault code,
so the issue is moot(so much for me).
A response to a poll about an aborted sequence, (assuming Position 2)
 would look like:
<Response
   xmlns="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1"
   xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   soap:mustUnderstand="1">
      <SequenceReplies groupId="mid://20040202.103832@oasis-open.org/">
        <ReplyRange from="0" to="5"/>
        <ReplyRange from="6" to="15" fault="wsrm:PermanentProcessingFailure"/>
      </SequenceReplies>
</Response>

NOTE: should we have a new fault code: "InvalidGroupId" for requests
concerning groups that are non-existent (possibly because already terminated?)