FINAL REL 94 Proposal.

Here is a "final  final" proposal for REL-94.

  <FinalRel94ProposalBegin/>

  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:

        o There can be one or more
GroupId sub-elements.

            
+ Values can be same or different.

        o There can be zero or more
SequenceNumberRange sub-elements

           
under a GroupId.

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

     [AI: Add this as a new issue and close it
as Resolved.]

 

 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

 all the patterns. [REL 75]

 [Open Issue: Whether we need to restrict the semantics for Response

             
Reply pattern has to be decided.]

 

 Tidbits:

  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 if it is 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.

 

 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.

 <FinalRel94ProposalEnd/>