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 Minutes of 4/13 Teleconf

Prelim minutes are attached.

Please post corrections on the list before next monday.

Tom Rutt

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

Title: Minutes of OASIS WS-RX Teleconference

Prelim Minutes of OASIS WS-RX Teleconference

April 13, 2006


Start Time:4:00 PM Eastern Daylight Time


Paul Freemantle acted as chair.


Textual Conventions


Ø  Action Item


§    Resolution


1         Roll Call

From Kavi:


xx of 4? voting members, meeting quorate


Tom Rutt agreed to take minutes.

2         Agenda Approval

1) Roll Call


2) Review and approval of the agenda


3) Approval of the Apr 06, 2006 meeting minutes



4) AI Review



5) Update from Editors


6) New issues since last conf-call

Watch for Marc’s email


7) Issue Discussion:

a> i089 suggest the restricted use of anonymous URI



b> i106 SequenceAcknowledgement:Final assumption of deliverability



c> i111 Sequence state in event of MessageNumberRollover


8) Any other business


Bob F proposed to defer issue 106.  Chris F have published proposals, but further work is required.


Doug D: can be move 111 before 89


No objection to changes.


Tom Asked that the Microsoft patent notice be put on the other business discussion. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200604/msg00038.html


Paul C: the statement is clear.


Doug D: I think we might want to discuss this if we have time.


Tom R: we might be better to read the notice and discuss it later.


3         Approval of the 4/6 minutes;



Tom R moved  Paul K seconded to approve 4/6 minutes


§    No objection minutes for 4/6 meeting approved..

4         AI Review

#0094: Marc G will produce a detailed proposal for i089 by fixing normal replay mechanism.
Owner: Marc Goodner
Status: Open – still pending
Assigned: 2006-04-03
Due: ---
#0097: have editors get a new namespace for next CD, given the use of ws addressing PR
Owner: Doug Davis
Status: Open – still pending
Assigned: 2006-04-03
Due: ---

5         Update from Editors

Doug D: all the resolved issues have been added to spec, except for issue 93.


Gil: we had no confidence in carrying out the resolution for issue 93.  We need help from Doug B.


Doug B: where are the problems.


Ø  Action: Gill and Doug will work to carry out resolution of issue 93.



6         New issues since last conf-call

From Marc’s email http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200604/msg00037.html 


6.1      Proposed-01 tightening-up the state tables

Jacques Durand


Title: Tightening up the state tables




(a)- RMD table: there is no way to transition from " none" to "connecting" state  (event "CreateSequence receive" is missing)


 (b)- RMD table: In the "event" entries: for events that concern "Faults", (e.g. Unknown Sequence Fault,  Terminated Sequence Fault), and when either RMS or RMD could generate such Faults,  it should be mentioned in table if the event is about receiving or generating such a Fault (assume it is "receive").


©- RMS table: mention that either the case of offered sequences is not handled, or add this case.


(d) "connected" state a bit ambiguous a name - too much transport related.


(e) these tables are more about sequences state than RMD/RMS states (as the same RMD/S can find itself in many states w/r to many sequences.


Justification: tables could be misleading to users if incomplete. Some developers might actually use them to implement an automaton that might miss some cases.


Target: core




(a)    add CreateSequence receive even that lead to connecting state.


(b)   Qualify each event as either "(internal)" or "(received)".


(c)   Add a line with event "offered sequence (received)" that transitions directly from none to connected.


(d)    Replace "connected" with "active", and "connecting" with "activating".


(e)   "This appendix specifies the non-normative state transition tables for RM Source and RM Destination." Replace with: "This appendix specifies the non-normative state transition tables for RM Source and RM Destination, relative to the management of a particular sequence."


No objection to accept proposed 01 as new issue.


6.2      Proposed-02 figure 2 out of date

Christopher B Ferris


Title: Figure 2 (cd3) [1] is out of date with the changes to the potocol




 Figure 2 (cd3) [1] is out of date with the changes to the potocol




does not reflect Close() operation


Target: core




replace Figure 2 graphic with this one


[1] http://docs.oasis-open.org/ws-rx/wsrm/200602/wsrm-1.1-spec-cd-03.pdf   




Christopher Ferris

STSM, Software Group Standards Strategy

email: chrisfer@us.ibm.com

blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440

phone: +1 508 377 9295

RM Protocol 20060407.ppt

Marc G: the final proposal also has to update the surrounding text.


No objection to accept proposed 02 as new issue.

6.3      Proposed-03 Add Max Msg Num to CSR

Doug Davis


Title: Add Max Msg Num to CSR



The createSeq/createSeqRes handshake already passes back the AckInterval which can be useful information to the RMS.  Knowing the max msg number that the RMD will support could also prove useful since not all impls will support the large # we mention in the spec. 



By the RMS knowing this information it may choose to use it to avoid getting the Message Number Rollover Fault and be able to deal with this situation in a much more graceful manner.


Target: core design




On the CSR add as an optional sibling to AckInterval:


Pseudo-schema (changes in bold):

<wsrm:CreateSequenceResponse ...>

    <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>

    <wsrm:Expires> xs:duration </wsrm:Expires> ?

    <wsrm:AcknowledgementInterval Milliseconds="xs:unsignedLong" ... /> ?

    <wsrm:MaxMessageNumber> wsrm:MessageNumberType </wsrm:MaxMessageNumber> ?

    <wsrm:Accept ...>

        <wsrm:AcksTo ...> wsa:EndpointReferenceType </wsrm:AcksTo>


    </wsrm:Accept> ?




and add...


This element, if present, specifies the largest message number that the RM Destination will accept for the specified Sequence. If omitted, the implied value is 9,223,372,036,854,775,807.


Update schema accordingly.


Paul F: I had proposed a note so solve this in issue 86.  I proposed all implementations should support the number (9trillion).  However I support this as a new issue.


Doug B: is this reopening a closed issue.  I am not sure we should open an issue that has been closed in the past.


Jacques: this issue is close to I13 closed.  It might be a reopening of I13.


Sanjay: I recall we had this discussion in the past.  However there have been changes to policy.  It may be reasonable to look at this as a new issue.


Sanjay: are there objections.


Doug B: I object, we have discussed this issue already.


Sanjay: lest carry on discussion for this new issue on the mailing list.  Defer discussion until future call.


Doug D: my single negative vote should not postpone.


Sanjay: I need more discussion, as maybe other members do.  I say we take it to email, and defer discussion.


No objection.


6.4      Proposed-04 "must understand" attribute for extensions to RM components

Gilbert Pilz


All of the Sequence Lifecycle Messages (<wsrm:CreateSequence>, <wsrm:CreateSequenceResponse>, <wsrm:CloseSequence>, <wsrm:CloseSequenceResponse>, <wsrm:TerminateSequence>, and <wsrm:TerminateSequenceResponse>) and RM Protocol Header Blocks (<wsrm:Sequence>, <wsrm:AckRequested>, and <wsrm:SequenceAcknowledgement>) define extension points for adding additional elements to the message, however, there is currently no mechanism for the sending party (e.g. the RMS in the case of a <wsrm:CreateSequence> message or the RMD in the case of a <wsrm:TerminateSequence> message) to indicate to the receiving party that it must understand the semantics implied by the extension element(s).  The usefulness of these extension points is therefore imited by the fact that, in general, the sending party cannot be certain whether the receiving party understood the extension or is simply ignoring it.





(add to Glossary section)


1.1 Glossary


The following glossary defines a set of terms used to describe some of the different messages related to WS-RM:


Sequence Lifecycle Message: A message that contains one of: <wsrm:CreateSequence>, <wsrm:CreateSequenceResponse>, <wsrm:CloseSequence>, <wsrm:CloseSequenceResponse>, <wsrm:TerminateSequence>, <wsrm:TerminateSequenceResponse> as the child element of the <soap:Body> element.


RM Protocol Header Block: One of <wsrm:Sequence>, <wsrm:SequenceAcknowledgement>, or <wsrm:AckRequested> elements.


RM Component: One of the elements that either make up the body of a Sequence Lifecycle Message or that appears as an RM Protocol Header Block.


Sequence Traffic Messsage: A message that contains a <wsrm:Sequence> header block.


Acknowledgement Message: A message that contains a <wsrm:SequenceAcknowledgement> header block.


(add to Section 3)


3.7 Extension Elements


The definition of each of the RM Components includes an extension point that allows the addition of elements to that RM Component. It is likely that specifications for a wide variety of extensions to these RM Components (termed “RM extensions” for the purposes of this discussion) will be developed over time and that some RM nodes might include the software necessary to implement one or more such extensions. An RM extension is said to be understood by an RM node if the software at that RM node has been written to fully conform to and implement the semantics specified for the XML expanded name of the outer-most element information item of the extended element.


An RM extension element MAY carry a mustUnderstand attribute information item. When the value of such an attribute information item is "true", the RM extension is said to be mandatory.


Mandatory RM extension elements are presumed to modify the semantics of other RM Components. Therefore, for every mandatory RM extension recieved by an RM node, the receiving node MUST either process the element or not process the element at all, and instead generate a wsrm:MustUnderstandFault. Tagging RM extensions as mandatory thus assures that such modifications will not be silently (and, presumably, erroneously) ignored by the RM nodes that recieve the messages containing extended RM Components.


(add to Section 4)


4.9 MustUnderstandFault


This fault is generated when an RM node (RMS or RMD) is presented with a Sequence Lifecycle Message or RM Protocol Header Block that contains an extension that is tagged with a wsrm:mustUnderstand attribute with a value of "true" and that node does not understand that extension element.




[Code] Client or Server (as appropriate)


[Subcode] wsrm:MustUnderstandFault


[Reason] Do not understand the extension marked as "must understand"


[Detail]    xs:any


No objections to accept proposed 04 as new tc issue.


7         Issue Discussion:

8         i089 suggest the restricted use of anonymous URI




Paul F: I proposed a new interaction to allow polling for messages from the client side.  This is for cases where the RMD cannot initiate connections with RMS.


Paul F: I proposed a getMessage request, with an identifier for a sequence, with a possible message id qualifier.  If no response are available there is a “no message” indication.


Paul F: I also added section 4.2 regarding an offer only model.


Paul F: the decision is whether this is in scope for the TC. Another issue is what the correlation ID would be.  My proposal is a balance of simplicity over power.  Also there is a concern on whether this is restricted to the anonymous URI.


Doug D proposal: http://lists.oasis-open.org/archives/ws-rx/200604/msg00023.html


Doug D: should we head down this path.  Our proposals are similar.  Should we solve this problem?  I would like a sense of the TC on whether we need a solution.


Sanjay: do we need solution for reliable messaging when RMS is not addressable.


Anish: I agree we need this solution.


Sanjay: whether polling is the preferred solution to this problem is still open.  Resend of request is another viable mechanism.


Stefan: a specific solution for anonymous clients, vs allowing the problem to be solved.  The spec should not get in the way of solutions.  However this problem is broader than rm.


Doug D: are you suggesting close with no action.


Stefan: I would have to review if the spec might need clarification words to allow the scenario.


Doug D: We need a solution in the spec.


Paul F: There are solutions to this problem. JMS has one solution.  I want to consider this.  If there was a standardized solution that can be used with wsrm I would like to use it.


Sanjay: do we want to have a solution in the spec today, or do we wait to compose.  My company needs a solution.


Stefan: anyone in this TC considering this should think about the scenario this is applicable in.  We need to ensure it works.


Tom R:  We need this, we can define a solution in our “namespace” which might be applied elsewhere.  If others can use it they should be able to.


Anish: I would like to move hat we add this functionality to the spec.


Marc G: we need to agree on a specific proposal, not just the need.


Anish: the first question is whether we need this capability.


Sanjay: first question is do we need this.  Second effort is on how to realize it.  The is a polling approach in both Doug D an Paul F proposal.  One question is whether polling approach is acceptable.


Chris F: such a motion cannot be binding.


Doug D: if anish wanted a polling approach I would second it.


Sanjay: is anyone opposed to taking polling approach to solve this problem.


Paul C: I agree we need to solve this problem, but I do not agree it should be rm specific.  We need a general solution to this problem.


Doug D: my proposal does solve a broader problem, and I would like it to be considered.


Sanjay: I see Paul C as asking that this might be better done outside this tc.


Paul C: I would like to hear Doug’s proposal in the remaining time.


Doug D gave a summary of his proposal.  The proposal has an EPR as the identifier of the originator of the connection which requires a polled return.  The Get message as a “me” identifier, which is the value of an epr sent in the reply to.  Our solution is more general, in that is allows more use cases.


Doug D: I would ask people to read the material we sent out on this.

8.1      c> i111 Sequence state in event of MessageNumberRollover



Paul F: the state tables on rollover do not agree with the text.


Title: Sequence state in event of MessageNumberRollover




The spec doesn't talk about what the continued state of a sequence is

after MessageNumberRollover.



The state tables have an entry that is not clear. We ought to define

what the state is after a rollover.


Target: core design




At line 519 after the following sentence:

If the message number exceeds the internal limitations of an RM Source

or RM Destination or reaches the maximum value of

9,223,372,036,854,775,807 the RM Source or Destination MUST issue a

MessageNumberRollover fault.


Add one of:


(a) In this case the RM Destination should continue to accept

undelivered messages until the Sequence is closed or terminated


(b) In this case the RM Destination should Close the Sequence.





Paul F: I prefer option a.


Doug D: I would like a change to the fault to add this rollover information.


Paul F: I think this is a separate issue.


Paul F: I am not against adding to fault but I prefer it be done as a separate issue.


Aniish: should -> SHOULD


Paul F: it needs to be SHOULD


Bob F: we need to make corresponding changes to the RMD state tables.


Paul F: that should be a separate issue.  The RMS would not issue rollover fault.


Bob F: should the cd 03 lines 518 and 519 need to be fixed.


Paul F: yes.


Paul could modifiy his proposal to add this new concern.


Doug D: I do believe an RMS can deliver a fault. The RMS might say the AS is going to far.  That is why it was stated the way it is.  The text should state “must generate”, not necessarily sent on the wire.


Sanjay: there are differing positions, so it maybe should be a new issue.


Chris F: nothing states an RMS cannot generate faults, transfer is a separate concern


Paul F: The concern is what the RMD does in this situation.


Sanjay: this proposal is aimed at what the desitnation should do when this fault is raised.


Doug D: I disagree. The rest of the spec talks about rms and rmd generating faults. The proposal needs to include both sides of the rm protocol.


Paul F: add “and RMS should continue to deliver …


Chris F:


Bob F: we decided to use “transferred” instead of “delivery”.  RMD state table no longer have Rollover as a state.  We may need to add the RMD state of rollover reintroduced.


Gil: why would rms generate source.


Doug D: if rms cannot deal with more than 3 messages.  If it reaches its limit, is should still send prior messages as a resend.


Considerable discussion ensued on message number limits, and prevention of message numbers allowed on the wire.


Sanjay: what is rmd supposed to do with fault from rms.  Could clarify that this fault is defined for rmd to send to rms.


Paul F: if rms wants to close sequence it can. This issue is to state what the RMD should do in the rollover situation.  I can accept the chris F proposal above as a friendly amendment.


Doug D moved to accept proposal from Chris F, Chris F seconded. “In this case the RM Destination should continue to accept , and the RM Source should continue to retransmit,undelivered messages until the Sequence is closed or terminated”


Bob: opening another issue for clarification on rms side might be acceptable.


Chris F: this text is regarding when this fault is generated.  I does not state which side generates the fault.  Assume it gets transmitted from rmd to rms.  This gives a clarifiction for that case.


Bob F: there might need to be state table clarificaitions.


§    Issue I111 resolved by accepting proposal from Chris F.

9         Any other business

Meeting adjourned at 5:30 EST.

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

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