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


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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

Subject: prelim wed PM minuts for f2f

the prelim Wed PM minutes for the f2f are attached.

Please post corrections to the list.

Tom Rutt
Tel: +1 732 801 5744
Fax: +1 732 774 5133
email: tom@coastin.com; trutt@us.fujitsu.com
Title: Day I (Sep 21, 2005)

Preliminary Minutes  WSRX TC Face To Face Meeting

 (Sep 21, 2005) - PM


10   Wed PM issue discussion

Decision to advance to i008 before returning to I009 resolution.

10.1   Issue 008 Policy Assertions Granularity


Tom Rutt summarized that, for example, the DA assertions might be applied at a level smaller than port type.


Some use cases would benefit by apply a different DA level to operations within the same Endpoint or port type.


Anish:  Some might even go down to message, which is smaller than Operation.


Paul: it might suffice to just take away the restriction in the current document.  The policy framework may be allow policy attachments lower than operation.


Claus: Currently, endpoint, operation, message and service are the attachment points for ws-policy.   The design of the assertion can put restrictions on where it can be attached.  The assertion definition must make it clear at which point it may be attached.  A given assertion type may only be attached to one point of attachment.


Anish: Do we need to restrict ourselves to ws-policy as it exists now?.  We should look at what our requirements are, and if ws-policy does not meet these requirements, the standard process for ws-policy could change it to meet our requirements.


Tom: The current rm policy assertion document has endpoint as the only attachment level for rm policy assertions.


Doug D: would removing DAs from the spec simplify the attachments of policy.


Anish: That would remove many issues and simplify the spec.


Doug D: not mentioning DA at all in the spec would simplify the specification.  The policy assertion would simply state (using RM).


Serge: it would be odd to have no place in the WSDL to indicate what level of reliability is required for the endpoint.


Gil: It seems you have to present a context on what the protocol is used for.


Doug D: in fact the current protocol does not depend on DA levels.  Removing all mention of DA from the spec would not change what goes on the wire.


Gil: People have expectations, and the way our DAs are structured is problematic.  We could break them up on a more refined basis (e.g, duplicate elimination, ordered delivery, guaranteed delivery).


Jacques: the current spec talks about DA and then protocol then states that they are orthogonal.   Duplicate elimination is a feature of the contract between rmp and receiving application.   It might be feasible to have a single spec which only has the protocol.


 Vadim:  The DA is the only qos which seems to benefit with a finer granularity than endpoint.  The protocol parameters are sufficient to be specified at Endpoint level.


Anish: I agree that removing DA from the spec will simplify the protocol description.


Sanjay: I think it might be a loss to take away the description of DAs.


Anish: the protocol enables DA, but its description says nothing about it.  We could either remove DAs, or change the protocol to reflect DAs.


Paul C: These DAs are design principles which the protocol definition was intended to enable.  Taking out DAs or moving them to another document would change them to a “rationale”, or “design principle” for why the protocol is the way it is.  For example the word “index” only occurs in the sql spec twice, and one is for the “index of terms” at the end of the spec.   I could go either way with Doug D discussion.  In fact the term “at most once” only occurs once in the spec.  It is a design principle.


Jacques: I like the comparison with SQL.  I still would prefer a protocol which can be flexible enough to refect DAs currently in use at the receiving end.


Chris F: One concern about removing DA concept, its absence could raise more questions by people following the progression of the spec.  It would require us to explain something which is unexplainable.  Rather than purge every mention, we could have an explanation of them as “design principles” for the protocol.   While the protocol does not depend on DA in use, the DA contract is still important between the RMD and Receiving application.   Being able to advertise what is going on at an endpoint instance is important.  I am kind of torn on this proposal.


Jeff M: People are going to ask “What kinds of assurances are enabled”.   In fact the DAs are explicitly listed within the scope of the TC.


Sanjay: the definition of message ID increasing by one is there to enable ordered delivery.  Thus ordered delivery is reflected in the protocol.


Paul F: I agree with Paul C that these are design principles.  The spec would be better to describe them as that.  However, if they are expressed in policy (as a result of i009) they will also be cast at meta data.


Paul F: we should go back to discussion of I009 since the only qos which needs granularity less than endpoint is DA.





10.2Issue 009 Continued

Message was sent out with a proposal by Chris F:


<wsrm:DeliveryAssertion mode="[AtLeastOnce|AtMostOnce|ExactlyOnce]"
ordered="[xs:boolean]"? ... >
A policy assertion that makes a claim as to the delivery assurance policy 
observed by the destination endpoint.
This required attribute specifies whether or not all of the messages 
within an RM Sequence will be delivered by the RM Destination to the 
Application Destination, and whether or not duplicate messages will be 
A value of 'AtMostOnce' means that messages received by the RM Destination 
will be delivered to the Application Destination at most once, without 
duplication. It is possible that some messages in a sequence may not be 
A value of 'AtLeastOnce' means that every message received by the RM 
Destination will be delivered to the Application Destination. Some 
messages may be delivered more than once.
A value of 'ExactlyOnce' means that every message received by the RM 
Destination will be delivered to the Application Destination without 
This attribute, of type xs:boolean, specifies whether, or not, the 
destination endpoint ensures that the messages within an RM Sequence will 
be processed in order. A value of 'true' indicates that messages will be 
processed in order. A value of 'false' makes no claims as to the order of 
processing of the messages within a RM Sequence. If omitted, the default 
implied value is 'false'.


Tom R: the definition of ordered needs to be change from “processed in order” to “delivered by RMD to application in order”.  The acks will be sent in the order received, not in the order delivered.


 Vadim: This proposal is between RMD and receiving destination.  It does not talk about Source.  At most once and at least once do have implications on the sending side.


Marc G: this is a separate assertion, it is not yet a parameter of ws rm policy assertion.


Chris F: it could be a parameter of policy assertion.  That is not what we are discussing now.


Claus: requirement for exposing DA on source side should be discussed.


Serge: Delivery assurance assertions deal with behaviour of destination. 


Edits of proposal:

<wsrm:DeliveryAssertion mode="[AtLeastOnce|AtMostOnce|ExactlyOnce]"
ordered="[xs:boolean]"? ... >
A policy assertion that makes a claim as to the delivery assurance policy 
observed by the destination endpoint.
This required attribute specifies whether or not all of the messages 
within an RM Sequence will be delivered by the RM Destination to the 
Application Destination, and whether or not duplicate messages will be 
A value of 'AtMostOnce' means that messages received by the RM Destination 
will be delivered to the Application Destination at most once, without 
duplication. It is possible that some messages in a sequence may not be 
A value of 'AtLeastOnce' means that every message received by the RM 
Destination will be delivered to the Application Destination. Some 
messages may be delivered more than once.
A value of 'ExactlyOnce' means that every message received by the RM 
Destination will be delivered to the Application Destination without 
This attribute, of type xs:boolean, specifies whether, or not, the 
destination endpoint ensures that the messages within an RM Sequence will 
be delivered in order, by the RMD to the AD.  Order is determined by the value of the RM message number.  Ordered delivery would mean that the messages would be delivered in ascending order of the message number value. A value of 'true' indicates that messages will be 
delivered in order. A value of 'false' makes no claims as to the order of 
delivery of the messages within a RM Sequence. If omitted, the default 
implied value is 'false'.


Doug: these delivery assurances are limited in the spec to the rmd and destination application.  Why are we discussing the source.


Paul F: if the source knows that at most once is in use at the destination, it can decide to throw away messages at the source, before they are assigned to the sequence.


Tom: given that the protocol requires the RMS always resend until ack, the sender does not need to know.  The only possibility is the if at most once is in use by the destination, it could decide to not put a submitted message into a sequence.


Serge: the sender must report not delivery with at least once, but with at most once it does not have to indicate failure of delivery.


Jacques: the proposed definition of ordered says nothing about what the sender must do.  It does not state that the sender must always assigning message number in same order.


Tom R: but this is stated elsewhere in the spec.  The protocol always requires the sender to always retransmit until ack, and to send the message numbers in order.  The behaviour of the RMS is brute force to allow any DA to be met at destination.


Paul F: can you raise this as a new issue?


Umit: section 2.2 already states this.


Duane N: Services are interfaces.  I am fundamentally concerned that we are violating principles of SOA.


Andreas: we need to change these definitions in the base spec as well.  The two specs need to agree.


Tom R: we can raise that as another editorial issue later.


Ashok: this is “observed” policy for the destination endpoint. We need a different word.


Serge: there is no consistency between the main spec and policy spec, and we are not clear about where it holds.


Paul F: it is clear that these DAs pertain to the destination endpoint,  We can raise another issue to make the main text agree with these new definitions.


Marc G: are these parameters of assertions?  This must be decided before I want to vote.


Anish: can someone explain what the difference between parameter and assertion is.


Claus: If this is its own assertion, we need logic or functionality in place to explain how this assertion is combined with other assertions.  This assertion implies that the assertion of rm protocol is also made.  


Paul F: you could only have this if the rm protocol is also asserted.


Paul F: we would have to define what happens if the delivery assurance assertion is made without the rm protocol use assertion.


Umit: we could allow multiple assertions, with the source selecting from them.  We need to determine if these delivery assurances are adequate first.


 Vadim: I would prefer a separate assertion, rather than a parameter.


Rebecca: I would prefer small assertions, which are composable.


Marc G: if it is a separate assertion it is not complete, since we have to define what it means in combination with all other assertions.  Is it ok to send DA assertion without the rm assertion.


Umit: we can accept this text now, and make decisions on the assertion composition later.


Paul F: we have no motion before the house.


Tom: could we not just state that you can only assert this if you also assert rm usage.


Paul F: another possibility would be to have this assertion imply that RM usage is also in use.


Umit: I move we accept this proposed text to close issue 009 , and we raise a new issue to decide on whether it is an assertion or a Parameter.  Seconded by Chris F.


Doug B: However the new issue resolution should allow changing the word “assertion” to “parameter”.


Paul C: I move to Table this motion, Marc G seconded.


10 yes

14 no

No abstains.


Vote on motion

18 yes

1 no

8 Abstains


Motion passed.


Doug B: I object to rushing this motion.


Action: Chris F to Raise a new issue on whether text to resolve issue 9 is to be an assertion or parameter.


Action: Tom to raise a new issue to align the main document text with resolution to issue 9.


10.3  Return to Issue 008

Tom: R: attaching DA of ordered at most once delivery to the endpoint, means that for operations which do not require ordered delivery, the RMD would still buffer their messages at the destination for ordered delive7r.  This would cause delays in delivery for some operations which are not required, and excessive usage of buffering resources.


Chris F: I would like to have more email discussion on a concrete proposal before we discuss this further.


Action: Tom R to submit a concrete proposal for discussion by the TC members on the email list.


10.4  Discussion of Issue 30

What are the obligations on RMD for use (or not) of Offered Sequence? core




       When an RMD accepts an offer of a bilateral Sequence, is it Obligated to use that

       Sequence for response messages to the endpoint that requested creation of the Sequence

       in which the offer was made?





        The text in section 3.4 makes no mention of the obligations, if any that the RMD has

        in accepting a CreateSequence with an Offer. The text at 480(pdf) reads:






        This element, if present, enables an RM Source to offer a corresponding Sequence

        for the reliable exchange of messages transmitted from RM Destination to RM Source.




       Chris Ferris



    Chris Ferris


     Proposal 12005-08-25


       As the wsrm:Offer is intended as an optimization, I believe that the RMD should be

       under no obligation to actually use the offered Sequence. Similarly, I believe that it

       should be made clear in the spec that the RMS MUST NOT presume that the offered Sequence

       will actually be used to ensure that there are no interop issues that might arise from one

       implementation making such an assumption and another that chooses not to use the offered

       Sequence (for what ever reason). I suppose that we *could* devise a wsrm:Decline child of

       wsrm:CreateSequence as a courtesy to the RMS that made the offer so that it could reclaim

       the associated resources rather than having to wait until the offered (but unused) Sequence

       expired. That would make it abundantly clear that there was no association. If we pursued

       the wsrm:Decline, then the text around lines 536-566 will need to be fixed accordingly.


Chris F reviewed the issue and his informal proposal above.


Anish: Another approach would be to say that semantics of create sequence response without accept element present, means that the sequence in the opposite direction was declined.


Sanjay asked for a sense of the TC before giving Chris an Action item to give a refined proposal.


Chris F stated he could write the proposal so it has two parts, part 1 clarify semantics. Part 2 add decline element.


Action: Chris F to provide a detailed proposal for voting by the TC.


10.5  Issue 26  Better support in handling space greed sequences



       In case an RM destination expects a large number of concurrent sequences, it may find itself

       in a position where maintaining the state of existing sequences takes too much resources. As a

       consequence, existing sequences may need to be terminated by the RM Destination, or new

       CreateSequence requests may be turned down, and denial of service occurs.

       COnsider a rate of message loss (and not RM-recovered) of about one for each million in average,

       over a sequence 1 trillion long (about 18,000, 000 times smaller than allowed maximum).

       Representing the state of such a sequence would require 1M intervals, with about 12 bytes to code

       an interval of (long) integers (long starting number + length on 4bytes) about 12Mb is used for

       the sequence state. For am RM Destination with tens of thousands of concurrent long-lasting sequences, it means that potentially terabytes of persistent space will be needed to store the state of these sequences. Also, the SequenceAcknowledgement element for such sequences may become extremely bulky (with such a rate loss above, could reach several Gb once the sequence gets big.)




       Space needs over time for sequences states is something unpredictable but manageable, (somehow like

       cache management). If one wants to ensure the scalability of the RM mechanism, such dynamic

       policies as:



        * (1) deciding to arbitrarily end some existing sequence (e.g. LFU)

        * (2) dynamically adjust the maximum sequence length of new sequences at creation time



       should be supported (though their specification should remain out of scope).

       For example, in many cases it is preferable to preventively limit the size of requested new

       sequences, and to decide that below a threshold of available memory, the maximum length of new

       sequences would get smaller. The RM specification is currently not open to such policies,

       mandating a fixed maximum to all sequences created regardless of resource status.


Related Issues


    Jacques Durand


    Jacques Durand


     Proposal 12005-08-09


       From raised issue


               (a) create another fault like "ResourceExhaustion" more explicit than "SequenceTerminated" fault,

               that allows the RM Source to understand the reason of such an arbitrary termination by the

               RM Destination.



               (b) In addition, if a smaller maximum has been dynamically decided by the RM Destination,

               communicate it to the RM Source via the CreateSequenceResponse.


Jacques presented the issue and his two proposed solutions.


Anish: Defining a fault makes sense to me.  However I have a question about the second proposal.   If the destination wants to limit the length of the sequence, most of the time the limit is on the total size of messages rather than the number of messages.


Chris F: the math assumes persistent gaps that stick around. With required retransmission the gaps will be filled “soon”.  It is not clear we have to maintain a lot of state with a large sequence.  We have a sequence refused fault, which might be confused with sequence terminated.   IBM has hardware to solve the resource problem.


Tom R: if the rmd runs out of buffer space for ordered delivery it might want to be able to signal that conditiong.


Paul C: the SequenceTerminated fault currently implies “unrecoverable condition” as the reason.  I do not understand what the sender would use with this extra information from an additional “resource exhaustion” fault.  Cannot this be put the detail element for the sequence terminated fault.


Chris F: I do not understand why the guy who gets the fault needs to know why.  There is nothing he can do to fix it.  The sequence terminated fault is used when something bad happens.


Tom: What happens if the sender exceeds the message number range of the receiving RMP


Chris F: I move to close this issue without change, Abbie seconded.


Chris F: there is a range exceed exception for that case.


No objections to motion.


Resolution: motion passed, issue 26 closed without change.


Paul C: I would like the issue list to point at the minutes which documented the decision.


Marc G: I usually link the resolution to the Minutes.


ACTION: Marc G will ensure that the issue list contains pointers to the minutes discussion which carried the resolution.


10.6  Issue 024  - WS RX policies not manifested on the wire




        Issue i009 asks whether WS-RX should define policy assertions to define

        various kinds of QoS properties for a message sequence.  This certainly seems

        like a good subject for discussion. What worries is something related.




        There is a tacit assumption that WS-RX policies will follow WS-Policy

        (latest public version Sept. 2004).  This specification does not state explicitly

        how to tell whether a message conforms to a particular policy.  The assumption is

        that one can examine the headers in the message and tell what policy is being followed.

        Thus, the effect of policies is manifested on the wire.




        But neither the suggested QoS assertions nor the existing WS-RX assertion that

        declares the retry-interval etc. will appear as message headers.  So, how do we

        tell what policy is being followed? Clearly, some other mechanism is needed.

        One way is for messages to carry the URI of the policy they adhere to.  Another

        is to define headers in the start-sequence and sequence-started messages that

        indicate policy information. I'm sure folks can come up with other good suggestions.


Ashok posted a proposed resolution at: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00242.html

My concern was that the RM policy assertion was not manifested on the wire
and the current WS-Policy document does not support this.
This afternoon we decided, on issue i009, that the policy was 'observed',
in the sense of wsp:observed that was contained in earlier versions of WS-Policy.  
Observed policies are not manifested in messages.
Thus, following this precedence, I suggest we close i024 by saying that:
- The assertion is scoped to the endpoint (this is the status quo)
- The policy is 'observed' - in the sense of wsp:observed  


Umit: Is this issue related to Issue 006, source based qos assertion..    If this is resolved, it would allow a policy assertion on the wire for the source to indicate to the destination.


Ashok: I am more interested in the destination to communicate to the source such things as retry interval.  I do not think any of these assertions result in messages on the wire.  


Paul F: the policy spec states there should be some message when policy is changed.


Jeff M: We do not have a standard spec which defines wsp:observed.  This may not ever be in the starndard process.  I am concerned about relying on wording in that spec.


Paul F: we can use the word observed, without referring to ws policy spec.


Anish: we could point to the definition of observed in ws policy.  If it changes we would need to change our spec.


Chris F: I would like to clarify the use of the word observed in this spec.  We have an rm-assertion with properties.  Policy is determined based on qname of assertion, not its contents.  Policy matching does not look at values.  If we want to indicate that a policy parameter is realized on the wire, we would have to elevate it to a full class assertion to compose with rm assertion.  I would rather we close this and deal with each individual assertion.


Ashok: I would prefer some clarifying words in the spec before closing this issue.



Sanjay: I understood this issue to be leading to the sending of policy parameters on the wire in the createSequence message.


Ashok: we do not have a strong use case for this.


Ashok the current spec does not state how the policy parameters, such as base-retransmission interval, are communicated from RMD to RMS.


Paul F: I heard that we should have a footnote to define what “observed” means.  We can give this as an editorial action if we close this issue.


Glen D: I would like to apply these policies on bindings.


Sanjay::binding is an endpoint policy subject.


Chris F: the question is whether it could be put on a port.


Paul C: it is more appropriate for a Binding.


Ashok moved to Close I 024 with editors adding clarification to the meaning of “observed”, Abbie seconded.


Chris F: perhaps we should keep this open so we remember the concerns.


No objection to adopting motion.


Resolution: Isssue 24 closed with clarification of meaning of observed to be added to spec.


Action: Ashok to write proposed clarification text on meaning of “observed” in this spec.


10.7 Issue 25 - form of seqAck when RMD has received no messages




        Consider the following scenario: an RMS establishes a Sequence with CreateSequence

        and transmits a single message that is NOT received by the RMD. It then follows that

        with an AckRequested message. What is the correct form of the SequenceAcknowledgement

        expected? Should one be sent?





        The specification and schema require that a SequenceAcknowledgement element

        have at least one AcknowledgementRange child element (or a Nack) Yet, MessageNumber

        values start at 1 and increment monotonically by 1 for each successive message in a

        Sequence. Zero (0) is not a valid MessageNumber.


Related Issues



       Chris Ferris



    Chris Ferris


     Proposal 12005-07-20


    From raised issue



        Recommend that an RMD be required to respond with a SequenceAcknowledgement element

        containing exactly one AcknowledgementRange child element that has both the @Upper

        and @Lower attributes each carry a value of "0" to signify that no messages have been

        received for a given Sequence. e.g.




        <wsrm:SequenceAcknowledgement xmlns:wsrm="http://docs.oasis-open.org/whatever">








        <wsrm:AcknowledgementRange Upper="0" Lower="0">







Chris F gave a summary of the issue.  He stated that Doug B provided an alternative to send empty list.


Paul C: sending “0” seems appropriate in the case of no received messages, since the source can code easily using a “high water mark”.


Jacques: I prefer the empty sequence case.  I do not like reporting invalid sequence numbers.  “0” is not a valid sequence message number.


Anish: I prefer the empty group of ranges.  I nothing is there, the sender will not be confused.


Serge: the text states the sequence starts with message number 1, and monotonically increases.  The spec could just state that “0” is used for this special indication.


Paul C: the schema could be changed to put in MinOccurs=0 to cover this case.  I could live with this.


Glen D: it is easier to code with minOccurs=0, rather than using the value “0”.


Glen D moved to close the issue with the Doug B proposal, http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00122.html  using minOccurs=0.  Anish Seconded.


Chris F: I do not like sending empty things.


Glen D: it causes no problem.


Chris F: I would prefer that we have a complete proposal.  We do not have that for the “sending nothing” approach.


Abbie: I move that we amend the motion with a replacement motion of Chris F proposal, seconded by Chris F.


Paul C: The prose text has the text “one or more times”.  This text needs to say “zero or more times”


Abbie: I want to amend to go with Chris F proposal.


Straw Poll

Absence – 16

Use value 0 – 17


Too close to call from straw poll.


Jorgen: we have to clarify that we put in 0,0 for the range, and not allow 0 with an upper level in the range value.


Paul C: we should ask for a straw poll of Cannot live with empty case, vs not live with 0,0 range case.


Straw poll:

Cannot live with 0,0 - 4

Cannot live with empty ack range – 1


Lei Jin: In current spec the empty ack range is allowed with Nacks in use.  The empty range for no receipt is changing the semantics.  Explicit 0,0 is closer to existing semantics.


Paul F: finding no range currently make one look for NACKS.


Gil: the RMD would be confused in the case of NACKS.


Anish: this semantics could be clarified.


Tom R: the spec currently claims that the ackRange is optional.  It needs to be clarified whether that not presence implies the use of NACK.


Glen D: I do not like Nack in the first place.  The 0.0 proposal requires that only one range be included, however it is possible to send further ackRanges which would be erroneous behaviour.  Empty is best , but an alternative would be an explicit marker to “nothing received”.


Anish: we could include an attribute or an element in SequenceAck which indicates that nothing has been received.  This could not be used with NACK.


Doug B: upper and lower are invalid message numbers, and I would rather not turn an error into a valid indication.


Jorgen: the rat hole is on the meaning of zero.


Paul F: who agrees with Abbie’s replacement motion.


12 yes

11 no

4 abstains


Straw poll for using explicit indicator for no message receipt.

13 yes

10 agains indicator


Jeff moved to table the replacement motion to accept Chris F proposal to use 0,0 range to indicate no message received, Glen D seconded.


No objections to tabling.


Action: Anish to propose use of an explicit marker for NO messages received.


Bob F: we need a persuasive argument, since the issue is so evenly divided.


11   Discussion of Implementation Subcommittee

Paul F stated SC members should use their SC email list to discuss three points:


  • SC deliverables
  • Interactions with main TC
  • Plan of action


After agreement the Implementation SC will report their agreement to the TC as a whole.


Members can add themselves to the SC list directly on KAVI. 

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