OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Prelim Minutes for Tuesday WSRM meeting

The prelim minutes from Tuesday are attached.

Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Title: Here is the proposed agenda:

Here is the proposed agenda:

Preliminary Tuesday Minutes OASIS WSRM TC Face to Face Meeting

Oct 28, 2003
Meeting Oct 28-30, 2003 

Location: France Telecom R&D 
              801 Gateway Boulevard Suite 500
              South San Francisco, CA 94080


All days the meetings will be from 9:00 to 5:00 PM

Conference Bridge Details:

(10:15 AM to 12:00 Noon Pacific Time Tuesday)

(2:30 PM to 4:00 PM Pacific Time Wed and Thursday)


Dial-In numbers:

Toll Free - : 1-800-605-5167
International - : 1-719-457-0339
Passcode: 732072

1         Introductions, Review of Agenda and Identification of input contributions

The proposed agenda was circulated:

Here is the proposed agenda:


OASIS WSRM TC Face to Face Meeting


Oct 28-30, 2003

Location: France Telecom R&D

              801 Gateway Boulevard Suite 500

              South San Francisco, CA 94080


All days the meetings will be from 9:00 to 5:00 PM

Conference Bridge Details:

(10:15 AM to 12:00 Noon Pacific Time Tuesday)

(2:30 PM to 4:00 PM Pacific Time Wed and Thursday)


Dial-In numbers:

Toll Free - : 1-800-605-5167

International - : 1-719-457-0339

Passcode: 732072


*Proposed Agenda:*




8:30         Coffee

9:00         Introductions, Review of Agenda and Identification of input contributions

9:15         Triage of Issue Priorities and new WS-Reliability Editor’s draft

10:15       Break and opening of Conference Bridge

10:30       Roll Call

10/14 Minutes approval

Discussion of High Priority Issues (e.g., , Timing issues, Poll for Ack)

12:00  Tele-Conference Bridge Closes – Lunch begins



1:00         Walkthrough WS-Reliability Editor’s draft (resolve any comments, check against issue resolutions)

2:30         Break

3:00         Discussion of Unresolved Specification Issues

5:00         Homework assignments and meeting closure





8:30 Coffee

9:00 Review of Homework Assignments and Continued Issue Resolution


10:00 France Telecom Executive summary of interop demo statusw)

10:30 Break

10:45 Continue resolution of WS-Reliability Specification Issues



12:00 Lunch

1:00         WS Reliability Feasibility Demonstration (J. Durand)

changed to

Finish Polling discussion

Assess impact of Request/Response on Basic WS-R Schema elements


2:30         Break and Opening of Tele-Conference Call

2:45         Resume Discussion of Issue resolutions (possible votes)

3:30         Discussion on Conformance matrix

4:30         Conference Bridge Closes

                Discussion of Homework Assignments,

5:00         meeting closure




8:30 Coffee

9:00 Review of Homework Assignments/proposals

9:30 Continuation of Conformance Discussion

10:30 Break

10:45       Review WS-Reliability Spec / Schema and assign subteams to clean up descriptions and examples.

12:00       Lunch



1:00         Discussion of Timing for Deliverables and Interop Demo plans

2:30         Conference call opens

Concluding discussions and possible votes on pending resolutions

Finish review of WS-Reliability Spec and assignment of descriptive sections to subteams for completion.

Future Meeting Planning


4:00         Conference Call closes

Formal voting stops after 4:00 on thursday


5:00         Meeting Adjourns


Timeline from Boston minutes:

Potential timeline:

  • Nov 3: Candidate Committee Draft for TC internal Comments.
  • Nov 20:  second Candidate Committee draft for TC vote
  • Dec 1 – Begin Public Review - approved Committee Draft
  • Jan 1 – Public Review period completed.
  • Feb 1 – Submit approved Second Committee draft to OASIS for member approval.



2         Triage of Issue Priorities and new WS-Reliability Editor’s draft

Iwasa sent the email:

I have summerised remaining issues as follows.

The following information is based on the issue list on 9/30:



1.Issues "Accepted":

check during walkthrough on Tuesday pm


  ED-1: Define document formats

  REL-14: WSDL

  REL-16: Order and Sequencing

  REL-39: ReplyTo

  REL-40: TimeToLive - optionality

  REL-47: Retry count/time

  REL-53: Remove all mention of MessageId

  REL-56: Describe all configuration information in the spec

  REL-81: Maximum message lifetime/duration parameter

  REL-88: Change RefToMessageId to RefToGroupId/RefToSequenceNumber

  REL-98: SequenceNumber usage



2.Issues "Completed":

need to confirm during walkthru


  ED-3: Clean up generated HTML

  REL-36: Overlap of messageID and GroupID/Seq

  REL-37: Use of messageID in RFC2822

  REL-44: Duplicate elimination and time to live

  REL-51: Acknowledgment piggybacking

  REL-58: Need to update namespace identifier



3.Issues "Active" or "Unassigned" with no proposal:


  REL-22: Optionality

  REL-29: Mandatory features

Discuss during conformance section of meeting


  REL-38: Timestamp

  REL-45: Handling message delivery failure cases

  REL-50: Semantics of time to live

  REL-52: New rules for persistence

  REL-57: Ordering and Missing Message Behavior

  REL-97: GroupID lifetime (RemoveAfter)

Dive into these during teleconf.


  REL-49: Non normative WSDL annotations

  REL-96: Reliable WSDL req/resp


  REL-59 to REL-79 and REL-89 to REL-93 : Meet Requirement

Discuss during second walkthrough of document


  REL-80: Need a way to communicate configuration information

  REL-95: Configuration parameter visibility

Wait till after resolving the timing issues.


4.Issues “Active” or “Unassigned” with proposal:

  REL-31: Meaning of guarantee

  REL-32: Add new terms from requirements

  REL-34: Figure 4 needs refinement

  REL-35: Header processing order

  REL-82 to REL-86: Parameters

  REL-87: New WS-R Headers

  REL-94: Polling RM-Reply Pattern design

Discuss at earliest convenience.

5.New Issues to be considered:

  Section1: Introduction, WS-I

  Section2: Messaging model, and SequenceNumber

  Section4: SOAP Fault, adding a fault for MAX length of GroupId

  Section5: HTTP Binding

 (Section6: Reference)

  Appendix C. Futures List


  Schema for SOAP1.2


  Attachments, MIME

These need to be resolved before True committee draft for ballot  Discuss during scheduling discussion








2.1      Discussion of polling issue status:

Sunil sent proposal on Rel94:

Hi Tom,


 I'd like to table the following proposal for the Poll Binding pattern for further discussion.

 It is the revised Poll pattern  proposal based on comments I've received from Iwasa and others.


 It is still based on Headers. It involves overloading the <AckRequested> sub-element instead of  new Headers so that it is more consistent with others. The new proposal doesn't involve any new  Headers.












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

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


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






Question: is the poll message itself acked by the poll response? –

Sunil answered: without piggybacking, there is not a need to have the poll request itself acked as a reliable message.

Sunil stated that the only signal to the receiver that this is a poll request is the presence of the sub elements in ack requested.  He is flexible about alternative syntax versions.

Doug: we would have two semantics tied to one element, with different results depending on subelements.

Doug prefers a new header to hold the new element in the request.

            Call new header PollRequest, with the sequence of (groupID,seqNoRange) subelements

Sometime we have to align the names.

Sunil stated we would not need a new header for the response.

    *  <AckRequested> should not have any child elements if the ReplyPattern is not Poll. It should result in a Fault (InvalidRMRequets) if it has child elements for other patterns.

    * If the ReplyPattern is Poll, it may or may not have child elements.

          o If <AckRequested> element is empty, then it is indication to the receiver that sender may poll for a message receive at a later stage.

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

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

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

                + Values can be same.

          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 simplicity sake, we should mandate that all the messages in a group should use the same ReplyPattern.



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

 1)  <Request>


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

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





 2) <Request>


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

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

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

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





 3) <Request>


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

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


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

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





 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 mentionded in the Request, not just

 previously un-acked messages.



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

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

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

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


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

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



Question: do we need to distinguish a poll request response from a response-replyPattern response

Answer use the same response.

Potential issue on timestamp in response: - Payrits wanted a timestamp on the refToSeqNumberRange.  However, message header has a time stamp on it.




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




 No Comments on Email :-(

 Lets discuss at the F2F.




3         Tele Conference Bridge (10:30 am)

3.1      Roll Call

First Name

Last Name



Voting Level





France Telecom

















TC Chair



















NEC Corporation


















SeeBeyond Technology Corporation






Sun Microsystems






Cyclone Commerce

















Mitre Corporation












webMethods, Inc.





3.2      10/14 Minutes approval

Sunil moved to approve the minutes, Alan seconded.


No opposition, minutes approved.


3.3      Discussion of  Poll for Ack


Poll request will have a MessageHeader, which states reply pattern poll, and a Poll request header.


Response will look exactly like a normal ack response.


Have satisfied multiple acks in a single response..


Can use same syntax


Time stamp in message header is enough.


Sunil moved to resolve rel94 (poll) and rel75 (multiple ack) with the revised proposal above, Dock Seconded.


No opposition motion passed.


Sunil just confirmed that the reply pattern must always be on the response.  Poll Request will return poll, and and a response reply pattern will indicate response.

3.4      Timing issues:

  REL-38: Timestamp




Need to specify that it should not be changed between retries.



Add the following text in section 3.1.5 Timestamp:

A sender MUST NOT change the value of Timestamp, when it resend the same message.

Alan: disadvantage of using original time- after repeated retries the maximum message duration will be exceeded.

Jacques- sender need to ensure that expired messages are not sent.


  REL-45: Handling message delivery failure cases



This is not an issue with faults


While it could be argued as an implementation optimization, we feel it is better if we standardize it. It means trying to recover in an optimized manner from when-in-doubt, mismatch, negative cases etc.. and not necessarily at post-failure cases.


Few examples are:

If you have to retry for msg 'i' in a group (message ordering case), then Sender should retry for (0 to 'i'-1) msgs. whose ack. was not received. [[ Assumption here is retry count/interval is set at a message level ]]

If the Sender receives an ack. for msg 'i' in a group and it has a prior msg(s) in the same group for which it didn't receive acks., the Sender can retry those msgs.

Upon time-out (TTL expiration) simply log the error and not process it any further. Example could be Sender should check whether the TTL expired or not before it has to do any retries. Similar things apply for Receiver too for acks. etc.

Doug:  all this states is that you continue to retry messages which are not acked.

Sunil- this could be a best practice recommendation text, leave it open, but keep at low priority. Do not need to consider together


  REL-50: Semantics of time to live (now expiry time)

itle: Semantics of time to live

Description: Result of closing issue REL-44 is TTL must be clarified.

What effect on the protocol operation does expiry time have.


  REL-52: New rules for persistence

Title: New rules for persistence

Description: Foll0wing the decisions made on closing issue REL-36, we need to improve the description of persistence rules (especially for recipients). The input specification discusses storage requirements exclusively in terms of message identifiers stored for duplicate eliminiation and messages stored for re-ordering a sequence. This approach must be completely reworked and enhanced with the new approach to message identifiers. When can a recipient "forget" about a sequence? How long must an out-of-order message be stored prior to giving up on ever delivering it to the application? How do these time windows relate to the TTL (expiration) of an individual message? Within what window will a duplicate be detected? Numerous changes are required to the text after we make a few basic decisions on the approach.

Need to clarify the impact of timing parameters on protocol operation.


  REL-57: Ordering and Missing Message Behavior

Description: Split out from issue REL-16, from email: What is the behavior of a WSRM receiver that is ordering messages and one of the messages is never received, or at least not within the MET (timeout) of a subsequent message even though ACKing is being used?

For example: it receives msg #0, #1, #3. The MET for message #3 is 5 minutes so the receiver cannot wait more that 5 minutes for #2 to arrive. What does it do when the 5 minutes expires?

Patrick Yeementions a preference for option (a) below.

26 Aug 2003: Doug mentioned one option for (c) -- silently dropping later messages. Have we previously discussed an issue that solves this problem?

See REL-86 for additional considerations.

Proposal: Options:

(a) Send a fault back to the sender, notify the application, and abort all further ordering for the group.

(b) Send a fault back, deliver #3 to the app just before it times out, and continuing ordering all subsequent messages.

(c) Something else?

Jacques has made a proposal to resolve this issue.

Jacques stated there is a need to clarify the meaning of a).  Need to split in a1) and a2).

A1) abort further ordering, or group, but pass message to receiving app in an unordered manner

A2) Drop all pending messages.


  REL-97: GroupID lifetime (RemoveAfter)

Title: Group ID lifetime (remove after)



See original mail


If we retain sequenceNumber as optional, we need to clarify what the semantics of removeAfter are for a simple ack only case (i.e., sequenceNumber not present). Perhaps it would only pertain if duplicate elimination is requested (and then it would be the lifetime of memory for duplication elimination for that message). If we have the case of duplicateElimination with SequenceNumbers then the removeAfter attribute is the lifetime for the persistent state required for duplicate elimination for that group. For duplicate elimination and ordered delivery the text is probably ok as is.

Also need to clarify the affect of expiry time and remove after on duplicate elimination.


Open the floor for discussion.


Open floor for discussion of these issues.


Jacques summarized that there are three possible meanings of expiry time:

a)      has only business meaning, does not impace rmp

b)      impacts the memory management of receiver or sender implementation

c)      is for use in duplicate elimination (how long to hold the id persistently)


One proposal to solve all of these issues together.


Sunil sent mail:

My proposal would be:


  0)  Have MaxMessageExpiryTimeout and MaxGroupExpiryTimeout as RM

       agreement parameters. The latter should be greater or at least equal to the


  1) Make ExpiryTimeout sub-element and removeAfter attribute be made


  2) Have DefaultMessageExpiryTimeout and DefaultGroupExpiryTimeout as RM

       agreement parameters. The latter should be greater or at least equal to the



      DefaultMessageExpiryTimeout should be less than or equal to MaxMessageExpiryTimeout.

      DefaultGroupExpiryTimeout should be less than or equal to MaxGroupExpiryTimeout.


   3) If ExpiryTimeout doesn't exist on the message, the message has a

  DefaultMessageExpiryTimeout  value. If it does exist, it should be less than MaxMessageExpiryTimeout, if not, fault is thrown.


   4) If removeAfter doesn't exist on the message, the message has a DefaultGroupExpiryTimeout value. If it does exist, it should be less than MaxGroupExpiryTimeout, if not, fault is  thrown.


   5) For grouped messages, if subsequent messages have removeAfter, we could

say one of the following:

           a) The latest one takes precedence

           b) If the values are different, throw a fault

           c) ignore subsequent ones


      I'm okay with (a) or (b), but not (c)


   6) For the grouped messages (ordered or un-ordered), a message's ExpiryTime

       (one sent on the wire or the default value) shouldn't exceed the group's ExpiryTime

       (one sent or the defaulted one). If not, fault is thrown.


   7) For a grouped messages, the group information (Group & SequenceNumber) information

       is removed from the RMP's persistence cache if the last message is signaled (Status END)

       or the Group's time (the one sent or the defaulted one) expires.

Question on why this should also impact the duplicate elimination.  When the status is end and all messages have been received and processed by receiving rmp.


   8) For singleton messages (group with only one message), removeAfter is not recommended, if exists, should be more

       than the message time. For singleton messages, the message information is

       stripped from the RMP's persistence case once the message expires (one

       sent or the defaulted one).

Doug:  all these endpoints can not be determined by the receiver.  He stated that defaults do not help, since the time has to be identified by the message, because it cannot be measured by the recipient.

Sunil – that is what the timestamp is.

Tom: Defaults and max must be interval. Doug’s point is the receiver does not always know the group start time. 

Sunil – the group start time is the timestamp of the first message in group.  Then apply the intervals to derive the expiry times.

Jacques – need to refine what we expect from semantics for group max duration for remove after.  He stated it can be used to terminate open inactive groups. 

Jacques stated this cannot affect the timeout of each message.  Group can expire while message has not expired.

Question: what is difference in MEP and Group Remove after.

Group unordered could have long group time.  Individual messages can be expired before group expires.  For duplicate elimination the smaller of the two prevails.


Tom stated that some scenarios might be better served by a max idle time parameter (e.g., a heartbeat monitor sequence, do now know how long the patient will be in hospital, however if there is not a beat in 1 day, the sequence could be terminated.


Jacques stated we arrive at semantics of these parameters, then discuss whether they are protocol parameters seen on the wire or config parameters made know out of band.


  9)  DuplicateElimination & Persistence definition should be re-worded





12:00  Tele-Conference Bridge Closes – Lunch begins

4         Walkthrough WS-Reliability Editor’s draft .54


Examples would need to be ready and included in the CD for TC vote (nov 20 as of plan)


Terminology was rationalized.


ACTION: Iwasa and Tom took action to add new messaging model for polling, callback, and response reply patterns.


Rm request – rm reply


Then map to three reply patterns

     Response – on underlying protocol response

     Call back – on subsequent callback

     Poll response


Iwasa took action to update section 5 Http binding, to use reply pattern terminology.


Iwasa will add picture for pollRequest header with request header.


Iwasa will make the ref to group ID look multiple


Section 4 – could push soap 1.2 support to later version. 


Jeff M asked how much work is to do soap 1.2.


Sunil – Need to Change schema and fault section 4 for Soap 1.2.


Sunil stated fault header is for soap 1.1 requirements.  Soap 1.2 has a new thing called reason.  We do not have to do it.


Action: try to get soap 1.2 changes required identified by Nov 20 due date.  If not done, the first CD for vote probably cannot include soap 1.2.  Subteam of Jeff and Payrits to work on this.


Iwasa will post the result of this effort as version .60 to the draft site.

5         Discussion of Unresolved Specification Issues


Matrix for discussion of semantics of timing parameters:


Processing order constraints:

  • Receiver RMP must check for message expiration before returning ack
  • Then, If not expired, Receiver RMP executes duplicate ID check.


Bob F scenario 1):

  • First message sent, ack gets lost.
  • Message retried, but received after expiry time.


With scenario 1, the sender will not know if the first message was delivered to the receiving app by its RMP.


Does receiver ack



Effect on Guaranteed Delivery

Effect on Duplicate elimination

Effect on Ordered Delivery

MesgExpiryTime - Last time the message should be made available from rmp to application

Message persistence on sender is bounded by this time.

Receiver RMP sends back ack for non-expired RMRequest, and makes available to application.

Receiver RMP sends back fault for expired RMRequest, including refToGroupID, and does not process further.

After processing for guaranteed delivery (at  left) do duplicate check only for non-expired rm requests .

If duplicate detected, do not make duplicate available to the receiving application.

If not expired and duplicate not detected

               If ordered delivery not in use, make available to receiver app

               If ordered delivery is in use, retain for proper order of making available to user.

Note- Rel57 resolution will determine what to do when: a) message is expired while waiting to be delivered, this can break the sequence processing; b) when message being waited for is never seen by ordered delivery processing










Doug: What is the processing order requirements for RMP checking constraints on rm request message?


Alternate proposal from sunil:

  Processing order constraints:

  • Receiver RMP must check for messag expiration (?on group remove after),
  • if expired send a fault with refToGroupID present.
  • If not expired,
    • persist information, and the return ack
    • Receiver RMP executes duplicate ID check.
      • If duplicate detected discard duplicate message
      • If duplicate not detected
        • If ordered delivery not in use, make available to receiver app
        • If ordered delivery is in use, retain for proper order of making available to user.



Jacques: alternative Semantics of remove after:

  • Purpose is: to Make sure that we do not have open ended inactive groups causing receiving RMP to keep rm-message state forever.  Consequence of this – remove after and expiry time are orthogonal.  RemoveAfter should not have impact on messageLife processing.   With this alternative, remove after should only be enforced when all the messages of the group have been successfully made available to the receiving app.  The name would have to changed with this alternative view. State is not deleted until the group processing is complete.  Retire the group state after removeAfter, unless there are any non-expired messages.   If there are non-expired messages, keep group open until all messages expire.  When all the messages of the group are made available to the user (in proper order), the group is retired after the RemoveAfter time.
  • Once the removeAfter time is reached, the entire group state is removed from persistence, regardless of whether messages are waiting for delivery or not.   Received Messages waiting for receipt of prior messages in sequence are discarded when group state is removed.


The second proposal is implied by the current spec wording.


The second alternative will cause the same or less delivered messages to the user.


If we had a Protocol requirement on sender rmp that (given there is a sequenceNo present)

·        It always sends both expiryTime and RemoveAfter

·        It always sends the same value for remove after for every message in the group, and,

·        Value of remove after for the group must always be greater or equal to the expiry time of the last message in the group


Sunil: the third bullet is the only important one.  Perhaps the first message sending the removeAfter is enough. 


Doug: one easy thing, is to make only the message with status=Start allowed to send the group ID.  If the first message is not received, the group state would not be initatiated.


Another alternative:  Sender keeps sending the removeAfter attribute until it receives the first ack for the group.  (since we decided that ordered deliver requires both duplicate elimination and guaranteed delivery).


Jacques:  boundary case: unordered group, with only duplicate elimination (not guaranteed delivery).


Tom suggested: -One way to fix: require that group is not set up until the first ack is sent.  This would require sender to employ guaranteed deliver on the group, until the first ack is receive, and then it could turn it off.


Bob – this approach has some advantages for short groups, high bandwidth high latency channels.



Then the second alternative would give the same behaviour of the first alternative.


Question about singleton- Do not allow removeAfter to be present for singleton groups.


Restated: RemoveAfter should only be present if SequenceNo is present.  This constraint cannot be expressed directly by the schema, since remove after is an attribute of GroupIDElement, rather than sequenceNo element.


Discussion on idle time:


Tom’s monitoring scenario 2)

Every 5 minutes the weather station sends a crucial reading as reliable message.  It does not know when it will stop transmitting, but when its battery dies, it will no longer deliver messages.  The idleTime would serve such  a scenario.


However, the sender could always terminate one sequence, and start another.  The sequencing of the boundary messages (end of one seq, and beginning of another) is not guaranteed in such a case.


Idle time could be a receiving rmp global policy, to self terminate.


General problem: what does receiver rmp do when it receives a message for a terminated group.   Since the group stated is removed, the receiver rmp will treat the message as a new sequence , where the intial messages have not yet arrived.  It will be received after the remove after time.  This is not a problem with the protocol constraints above, since it will be an expired message.


Bob F – we could require that the first message sent in a group MUST assert guaranteed delivery.   It will eventually get there (until it times out).


Recess at 5:00 PM.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]