Re: [REL-94] Amended Poll Reply Pattern Binding Proposal

All -

 The group agreed to accept the proposal with one change:

        - Move the "request for
poll" into a new Header rather than

          overloading
"AckRequested".

 Here is a final proposal for REL-94 with the required changes.

  <Rel94ProposalBegin/>

  So the initial msg. with the intent for Poll ReplyPattern Binding
will have

  ReplyPattern set to Poll and it will have AckRequested sub-element

 

   <MessageHeader>

      ....

      <ReplyPattern>Poll</ReplyPattern>

   </MessageHeader>

   <Request>

       <AckRequested/>

     ...

  </Request>

 The poll request will have a new Header called PollRequest.

 An example is as follows:

   <PollRequest>

         <GroupId value="a.b.c.com/xyz/001"
>

           
<SequenceNumberRange From="1" To="10" />

        </GroupId>

        <GroupId value="a.b.c.com/xyz/002"
/>

   </PollRequest>

 Specifics:

Intent for Poll pattern is done using ReplyPattern set to Poll and existence
of the AckRequested sub-element in Request Header.

Actual Poll request will be sent in a  separate Header called PollRequest

PollRequest Header could be the one of  following:

If it has one or more GroupId sub-elements, then it is a indication that 
sender wants to Poll previously sent message(s).

If it has one or more GroupId sub-elements, then <DuplicateElimination>
and <MessageOrder> should not exist and if exists are ignored.

There can be zero or more GroupId sub-elements.

Values can be same.

There can be zero or more SequenceNumberRange sub-elements under a GroupId.

If there is no SequenceNumberRange sub-element, Response should include
all received messages in that Group.

For Poll Request, it should only have MessageHeader and PollRequest Header.
It shouldn't have the Request Header. So essentially one can't Ack a Poll
request. No useful use case to support it.

For simplicity sake, we should mandate that all the messages in a group
should use the same ReplyPattern.

The Response for a Poll request will have a MessageHeader and the ReplyPattern
sub-element will be set to Poll. [The group agreed to generalize the
rule  for all patterns].

 So possible requests are (assume ReplyPattern is Poll for all the
below):

 1)  <PollRequest>

        <GroupId value="a.b.c.com/xyz/001"
>

           
<SequenceNumberRange From="1" To="12" />

        </GroupId>

     </PollRequest>

 2) <PollRequest>

        <GroupId value="a.b.c.com/xyz/001"
>

           
<SequenceNumberRange From="1" To="5" />

           
<SequenceNumberRange From="7" To="7" />

            
<SequenceNumberRange From="10" To="12" />

        </GroupId>

   </PollRequest>

 3) <PollRequest>

        <GroupId value="a.b.c.com/xyz/001"
>

           
<SequenceNumberRange From="1" To="5" />

        </GroupId>

        <GroupId value="a.b.c.com/xyz/001"
>

           
<SequenceNumberRange From="6" To="12" />

        </GroupId>

   </PollRequest>

 While all the 3 cases are valid, (1) will be the most efficient
and should be recommended.

 And the receiver is REQUIRED to send back requested Acks for message(s)
that were

 received already.

 Note that the Response will include all received messages in the
range mentioned in

 the  Request, not just previously un-acked messages.

 <Response>

     <RefToGroupId value="a.b.c.com/xyz/001">

         <RefToSequenceNumberRange
From="1" To="5" />

         <RefToSequenceNumberRange
From="7" To="7" />

        <RefToSequenceNumberRange
From="10" To="12 />

   </RefToGroupId>

   <RefToGroupId value="a.b.c.com/xyz/002">

         <RefToSequenceNumberRange
From="1" To="8" />

   </RefToGroupId>

 </Response>

 It was also decided to use the same syntax for bataching acks
in

 Callback pattern case. [REL 75]

 Tdibits:

  1.This request will be sent to the same endpoint as the original
message(s) are sent..

  2.Poll request for a message sent to another endpoint MAY result
in InvalidGroupId fault.

  3.Since it is defined as a Header, it could be defined in the
SOAP Binding part in the

     if desired.

 Possible failure faultcodes are:

  1.InvalidGroupId:  Even if one of the GroupIds are wrong
or invalid, this fault will be sent.

  2.InvalidSequenceNumber: Even if one of the SequenceNumbers
is wrong or invalid,

     this fault will be generated and sent.

  3.InvalidRMRequest: If the AckRequested element has one or more
child elements for

     Response or Callback poll pattern.  Or,
if there is some mis-match of ReplyPatten

     types for the messages in the same group.

 Essentially, all or none approach wrt to Faults. We should be
able to share the above

 Status values with Fault  Codes. Note both  are QNAME
types and hence shareable.

 Piggybacking of a Poll request could either be disallowed or should
be tackled along

 with the general piggybacking problem.

 <ProposalEnd/>

 

 -Sunil