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 4/6/ teleconf

Prelim minutes attached.

Please post corrections to list before 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 6, 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 F2F meeting minutes



4) AI Review



5) Administrative issues

a) Editors update

b) telecon sponsorship for next meetings


6) New issues since last meeting

Watch for Marc’s email


7) Issue Discussion:


i108 misplaced guidance on fault handling



i106 SequenceAcknowledgement:Final assumption of deliverability



i089 Suggest the restricted use of anonymous URI



i096 Complete the state tables



8) Any other business


Chris F stated he would like to defer Issue 89.


No objection to defer Issue 89.


3         Approval of the 3/23 F2F minutes;



Tom R moved  Doug D seconded to approve F2F minutes


§    No objection minutes for F2F meeting approved..

4         AI Review



#0093: Paul F will produce a detailed proposal for i089 with usage of Get Message

Owner: Paul Fremantle

Status: Closed

Assigned: 2006-04-03

Due: ---


#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: ---


#0095: Matt, Bob, and Tom will provide an amended state table before the April 6 teleconference

Owner: Matt Lovett

Status: Closed

Assigned: 2006-04-03

Due: ---


#0096: Paul F will post a version of interop Scenario document on Kavi for access by entire TC

Owner: Paul Fremantle

Status: Closed

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: ---


#0098: Chris F and Anish will propose appropriate text for resolution of I108

Owner: Christopher Ferris

Status: Closed

Assigned: 2006-04-03

Due: ---


5         Administrative issues

5.1      Editors update


Doug D: no changes since Face To Face.


Paul F: what are plans for producing new draft incorporating F2F changes in.


Doug D: I would like to have it done before the next phone call.

5.2      b) telecon sponsorship for next meetings


Gil volunteered to get a bridge for the next call.


Paul Knight volunteered for the subsequent call.

6         New issues since last meeting

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


Proposed 01

Title: dangling reference to RMAssertion acknowledgement timing params



From cd03[1] lines 564-566:


The timing of acknowledgements can be advertised using policy and

acknowledgements can be explicitly requested using the <wsrm:AckRequested>

directive (see Section Request Acknowledgement).


Justification: dangling reference


Target: core




Suggest that the text be changed to read:


Acknowledgements can be explicitly requested using the <wsrm:AckRequested>

directive (see Section Request Acknowledgement).


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




Christopher Ferris

No objections to accepting proposed 01 as new issue.


Chris F moved, Doug D seconded to accept proposal for proposed 01.


§    No objections, proposed 01 to be resolved with proposal from Chris F.

Proposed 02

New Issue posted by Paul Freemante:

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.




Sanjay: would not the creater of messageID know when rollover happens.


Doug D: there is a third option, do nothing at all.  Anything else lower is bad.


Chris F: RMD can close sequence if it does not like multiple rollover messages.


Tom R: closing the sequence seems acceptable solution, should discuss on email.



No objection to accept proposed 2 as new issue.




7         Issue Discussion:


7.1      i108 misplaced guidance on fault handling



Chris F proposal posted as http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200604/msg00017.html

As per my AI, I have noodled on this with Anish, Gil and Doug and have come up with the following revised proposal for i108 [1]


 When the processing of an RM protocol header block (with the exception of Sequence) generates  a fault, and the purpose of the containing message is not exclusive to that RM protocol header  block, then the receiving  endpoint MUST continue normal processing of the message unless  the generated fault is a SOAP MustUnderstand fault.


Gil had suggested that we add to the glossary a set of terms that could help us in describing

certain types of messages. I agree. Here's a start:


Sequence lifecycle messages:

       A message that contains one of: CreateSequence, CreateSequenceResponse, CloseSequence, CloseSequenceResponse,

       TerminateSequence, TerminateSequenceResponse as the child element of the soap:Body element.


RM protocol header blocks:

       Sequence, SequenceAcknowledgement, AckRequested


Sequence messsage:

       A message that contains a Sequence RM prototcol header block.


Acknowledgement message:

       A message that contains a SequenceAcknowledgement RM protocol header block


[1] http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i108


Christopher Ferris


Anish: I am convinced now that MUST makes sense.  My concerns are all covered by the MUST statement.


Chris F moved, Anish seconded to resolve issue 108 by accepting proposal.


§    No objections, issue 108 closed by accepting proposal.

7.2      i106 SequenceAcknowledgement:Final assumption of deliverability




As an alternative to the proposal I made in http://lists.oasis-open.org/archives/ws-rx/200603/msg00185.html the following will also satisfy my concerns:


Since implementations may have various methods of delivering messages to the application and may or may not include some sort of persistence, it may be instructive to annotate the ack sequence with information indicating which messages were actually delivered or otherwise safely transferred to the RMD.


Sequence acknowledgements indicate simply that the RMD layer has received the message, and provides no information concerning their subsequent processing or delivery.  SequenceAcknowlwdgement/Final received upon sequence closure may therefore provide ambiguous information to the RMS concerning the potential deliverability or delivery status of received messages based in part on message ordering contracts that may exist between the RMD and the application which are invisible to the RMS.


What is proposed is the inclusion of two additional attributes to the SequenceAcknowledgement/AcknowledgementRange element that would define message upper and lower bound ranges that have been delivered by the RMD to the application


A partial proposal is contained in the attached pdf based on CD03.


Please see the insertions in lines 560 and 603.


If this proposal is accepted, then the exemplar in lines 570-580 would need to be expanded as well as schema.


Bob F:  Taking responsibility means RMD can deliver the message.  Since then I proposed a definition of range attributes .


Matt: I think this goes beyond scope of spec.  If the sender knew ordered delivery is in place, it will know something might not be delivered, even after acknowledged.


Stefan: why do we need these new mechanisms.


Bob F: we have know way otherwise, what will be delivered.  It is possible to implement RMD that messages persist before being acked.  But I cannot deliver before delivering the prior. 


Tom R: The ack ranges give info to have the client to know that maybe it is not delivered.  Quality of implementation might buffer these “dangling’ out of order messages for the user application to retrieve them..


Bob: I would agreed if you could restart a sequence.


Chris F: all the info sender needs to know is in the Ack.


Jacques: It is valuable information to have rms side know what is going on in RMD side.  However, a special message fault could do job, say “message not delivered”.


Paul F: My concern is that we do not have a definition of delivery, which was a conscious decision.  Middleware layers deliver to the next layer, but there is no final definition of delivery.  The correct way to do this is to compose with some other spec (say transactions) to get the concept of completion.


Paul F: with the concept of service, you have given the message to be delivered, and that is enough.  I oppose adding new mechanisms to assert delivery.


Jacques: 2.1 glossary has some existing text about “delivery” which needs to be clarified.  I question the need for these definitions


Chris F: Using RM between enterprises, purpose of RMD is to pop on a MQ series queued.  I would like to consider it delivered from the point of view of RMD.


Glen: it is clear that you do not have to resend it.


Bob F: but if the RMD supports ordered delivery, there can be messages which are never delivered since they are waiting for a prior.


Tom: but the conservative RMS would have to assume that the later messages would not be delivered within the sequence.  The definition of the ordered sequence requires this.


Chris F: The spec enables what is needed for delivery in order.  All the destination the destination needs to know regarding order within the sequence is provided in the message.


Glen: Different mechanisms have options on what to do in particular situations.  For any real application of what are doing there is a notion of delivery.  JMS states on connection one can get ack of receipt, or ack that the application has taken off the queue.  I think Delivery assurances that are well defined would be useful.


Tom: The RMS knows that the RMD is waiting on a prior.  It can send the prior to get it delivered.  If it does not resent, then the contract of “ordered delivery” does not allow delivery to the sender.  Thus the RMS must assume it was not delivered.  I think that the only thing we need to do is to clarify that the sender knows that ordered delivery is in use.   


Dave O: the meaning of delivery of message is application specific.  Will the delivery mechanism recover from failure.  I would like to keep the protocol as to what you can test on the wire.


Glen: there is a fruitful middle ground, where the application can give meaning of how it can be interpreted.


Tom: Given the sender might not know whether ordered delivery is in use, I think a fault might be more appropriate, for the non delivered ordered delivery case, as Jacques pointed out earlier.  If RMD knows it is not delivered because it is out of order, then it has information to give to the sender.


Chris F: that fault would just state “it is not delivered now”.  It may not be delivered, or even deliverable.  We are getting back into delivery assurance discussion.  Application level acks can be added to the mechanisms we have here.


Bob F: another alternative is outage event is the ability to restart a sequence.  If a way existed to restart a sequence this could solve the problem.  It is the edge cases for terminations that I am concerned about.


Chris F moved to close I 106 with no action, Stefan seconded.

Bob Objected to motion.


Anish: would Bob’s proposal to clean up language to make it clear what ack means.


Bob F: a clarification that ack does not imply enablement.


Paul F: given Jacques point about glossary, we have to change that as well.


Tom Rutt moved to table, Jeff M seconded motion to table.


§    No objections to table motion.


7.3      i096 Complete the state tables




Matt posted a new PDF file.  http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200604/msg00011.html


The state table does not have empty boxes or question marks.


Bob F: I will be opening two issues against the table.  Sequence Ack Final on processing of ranges, and when elapseExpired event is triggered by time or by something else.


Bob F: the state tables are complete.  However there are still things we need to do to clean up.  Rollover operations changes could be made.


Jacques: in the event column it would be good to make it clearer that the “fault” related events, are we talking about generating this or receiving this.  Unknown sequence is an event generated by RMS.


Tom: this table is now cleaner, we can clean it up with other issues.


Matt: I would prefer we accept this table as is for now, using new issues to fix.


Bob F: I have questions about removal of the rollover state.


Paul F: If we accept now, can editors get into next WD.


Doug G: Yes.


Paul F: it might be best to raise new issues on inconsistencies.


Bob F moved to accept Matts proposal to close I096, Seconded by Tom R.


§    No objections, new state tables accepted, as closing issue i096.

1         Any other business

Meeting adjourned at 5:30 PM

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]