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

Motion

§ Resolution

1 Roll Call

From Kavi:

xx of 4? voting members, meeting quorate

Tom Rutt agreed to take minutes.

2 Agenda Approval

Agenda

1) Roll Call

2) Review and approval of the agenda

3) Approval of the F2F meeting minutes

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/17492/MinutesWSRX-f2f-032306.html

4) AI Review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

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

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

i106 SequenceAcknowledgement:Final assumption of deliverability

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i106

i089 Suggest the restricted use of anonymous URI

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i089

i096 Complete the state tables

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i096

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;

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/17492/MinutesWSRX-f2f-032306.html

Tom R moved Doug D seconded to approve F2F minutes

§ No objection minutes for F2F meeting approved..

4 AI Review

   http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

#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

Description:

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

Proposal:

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

Cheers

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

Description:

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

Justification:

The state tables have an entry that is not clear. We ought to define what the state is after a rollover.

Target: core design

Proposal:

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

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

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

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

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i106

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200604/msg00007.html

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

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i096

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

ws-rx message

1 Roll Call

2 Agenda Approval

3 Approval of the 3/23 F2F minutes;

4 AI Review

5 Administrative issues

5.1 Editors update

5.2 b) telecon sponsorship for next meetings

6 New issues since last meeting

Proposed 01

Proposed 02

7 Issue Discussion:

7.1 i108 misplaced guidance on fault handling

7.2 i106 SequenceAcknowledgement:Final assumption of deliverability

7.3 i096 Complete the state tables

1 Any other business