Prelim Minutes of OASIS WS-RX Teleconference

Nov 16, 2006

Start Time:4:00 PM Eastern Daylight Time

Paul F acted as chair.

Textual Conventions

Ų Action Item

Motion

§ Resolution

1 Roll Call

From Kavi:

meeting is 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 Nov 9, 2006 meeting minutes

http://www.oasis-open.org/apps/org/workgroup/ws-rx/document.php?document_id=21095

4) AI Review

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

5) Report from the Implementation SC

6) New Issues

7) Discussion of PR Issues

PR001 WS-Addressing comment on ws-rm related to use of extended anonymous uri

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i001

PR007 RM Destination lacks a mechanism for cleanly terminating inbound sequences.

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i007

PR009 "Duplicate Elimination" and "Message Ordering"

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i009

PR012 Anonymous and AcksTo EPR scenarios

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i012

PR013 SequenceAcknowledgement protocol response for AcksTo = wsa:anonymous

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i013

PR014 Composition with WS-Addressing

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i014

PR015 RMD polling

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i015

PR016 2nd Protocol Invariant, none and nack

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i016

PR019 Use of AckRequested

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i019

PR022 RMD cannot detect some incomplete Sequences

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i022

Motion tabled from last week:

Accept Gil's proposal.

7) Any other business

15 minutes to straw poll, then simple issues, then discussion of Pr001.

3 3 Approval of the 11/09 Minutes;

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21095/Minutes%20WS-RX%202006-11-09.doc

Marc G moved to approve 11/09 minutes subject to roll being added to posted version, Charlton seconded.

§ No objections, minutes of 11/09 approved.

Minutes posted as revision with attendance list at:

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21231/Minutes%20WS-RX%202006-11-09b.htm

4 AI Review

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

#0111: Paul and Bob to work out joint WS-RX/WS-Addressing forum for further discussion of pr001 issue.

Owner: Paul Fremantle

Status: Open – still on hold

Assigned: 2006-10-05

Due: ---

#0112: Create a proposal for the piggybacking ack actions

Owner: Paul Fremantle

Status: Closed, Paul provided proposal

Assigned: 2006-10-26

Due: ---

5 Report from Implementation SC

Doug D: nothing changed since last week.

Marc G: I posted an SX TC interop description. However there has been no further discussion on SC list.

Paul F: we have found no new issues so far.

6 New Issues

Paul F: One new issue was posted by Kevin Houston.

Marc G: I will forward that to the list and give it a number. Also a new issue just came in from Pete Wenzel.

Kevin Houstton – Issue 35 – delivery assurances

Pete Wenzel – Issue 36.

Bob F asked if we could vote on the resolution for issue 36.

Many asked for time to read.

7 Discussion of PR Issues

Straw poll results:

24 for Marc G proposal

23 for close no action.

Doug D: we need more discussion.

Marc G: looking at results there is something that needs to be done. The votes for our proposal says it has problems to be completed before it can be voted on.

Dave O: are you saying we keep on working on it to get closer to consensus.

Marc G: I think we should keep working on it.

Gil: I am for continued discussion, of microsoft proposal, however it should be on an issue which actually exists. The PR001 regards a conflict with WS addressing. WS addressing may have no problem

Jacques: more work needs to be done, I cannot vote for Marc G proposal today, I am even less willing to vote with close no action. I do not know if WSA is done on this.

Anish: I agree with Gil, from straw poll discussion. IF wsa resolves as it is going, we might need a new issue for this. There is a new move for policy assertions which would help this.

Tom: Even if WSA is silent on special anonymous URIs, we should still consider the wisdom of defining a new special anonymous URI for our wsrm spec. I would prefer to have wsrm not rely on a special anonymous URI with id info.

Bob: Any group defining a special URI needs to define its semantics. WSA group seems to be trying to get out of the way.

Paul F: time to move on to light weight issues.

7.1 PR0025

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i025

http://www.oasis-open.org/archives/ws-rx/200610/msg00111.html

Doug D: moved to accept proposed resolution, Marc G seconded.

No objection pr 0025 closed with proposed resolution

7.2 PR012 Anonymous and AcksTo EPR scenarios

: http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i012

Description

2.5 Line 704-709

The following sentences needs to be refined or requires examples.

" When the RM Source specifies the WS-Addressing anonymous IRI as the address of the AcksTo EPR,

the RM Destination MUST Transmit any SequenceAcknowledgement headers for the created Sequence in a

SOAP envelope to be Transmitted on the protocol binding-specific channel. Such a channel is provided

by the context of a Received message containing a SOAP envelope that contains a Sequence header block

and/or a AckRequested header block for that same Sequence identifier."

Maybe some examples help reader understand what it meant.

It is not clear whether the SequenceAcknowledgement must be sent on

*its* back-channel of the underlying transport protocol.

e.g.,

Here is the following scenario:

1.CreateSequence has "Anonymous" value for AcksTo element.

2.RM Source sends a message A with AckRequested on HTTP Request.

3.RM Source sends a message B on HTTP Request.

Question:

In this scenario, does RM Destination have to send Sequence Acknowledgement for message A on the HTTP Response in 2, but disallow to send it on HTTP Response in 3?

Or does the spec allow to send it on the HTTP Response in 3?

The spec is not clear about the above scenario. The spec should clarify it.

MrGoodner1: http://www.oasis-open.org/archives/ws-rx/200610/msg00111.html

MrGoodner1: Proposal for issue 12: http://www.oasis-open.org/archives/ws-rx/200611/msg00134.html

Jacques: this issue is about the term backchannel, even though we have no particular transport binding.

Paul F: issue PR013 is almost the same.

Doug D: I do not understand the Goal.

Paul F: we could make it a SHOULD. I do not think this is easy to close with no action

Paul F: I wrote text for issue 13 which states that the backchannel of the ack requested should be used for the ack.

Stefan: how would a should help. You still have to support the case where other options exist.

Marc G: why be so specific about this, when we do not have particualar bindings.

Doug D: the spec already says the RMD MUST send the ack to the acks to address. It does not say when.

Gil: When the ack is sent is important.

Paul F: this is not easy to close, so we should move on to other easy issues.

Jacques: I agree this needs furthur discussion.

Agreement to move on to other easy issues.

7.3 PR001 WS-Addressing comment on ws-rm related to use of extended anonymous uri

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i001

There was discussion on how to proceed on resolving problems with Microsoft proposal.

Paul C: I would like to have discussion on what problems there are with the Microsoft proposal. We need to understand the message flows Doug has in mind.

Doug D: I have some use cases which need to be evaluated more fully against the proposal. I sent out a note earlier as:

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

Paul F: I think the proposal needs more work. I need to go thru some flows against the proposal.

Doug D agreed to explicitly list the flows he has concerns about in a prioritized order.

Marc G: Doug’s note is on the email list.

Doug D: first problem is on sequence faults. Sequence Faults are sent to the AcksTo EPR - this means that faults for the client->server sequence are sent to the AcksTo EPR - which may be anonymous.

Normally when we talk about MC being used we talk about it polling for messages related to the Offered Sequence not the outbound/client->server sequence. However, in order for these client->server Sequence Faults to be delivered the client MUST periodically poll for them. So in this proposal how do the Sequence Faults get returned?

Doug D: Second problem is on multiple hosts on sequence

Specific comments:

- Lack of support for multiple endpoints per Sequence.

Jacques: I beleive either approach could solve this multiple endpoints problem

Marc G: This could be supported by the Microsoft proposal. Doug’s scenario is not documented in the current spec, and Doug’s proposal is very surprising on this using wsrm anon uri.

Bob F: are these use cases represented in our interop scenarios.

Doug D: no.

Doug D another email: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200611/msg00047.html

Marc G: I want a clear enumerated list, these mails are not enumerated with names and importance.

Dave O: this discussion is not helpful. We need to synthsize viewpoints, rather than having diverse viewpoints.

Bob F: If we can get to the set of use cases that this protocol needs to support, we can have a more objective criteria for making a decision on this issue.

Jacques: For this we need a small list of well defined use cases which we can used to evaluate the proposals. We may decided to reject some use cases.

Doug D: on the processing model problem.

- Restrictions on RM Processing model.

Base specifications should, within reason, try to avoid restricting the

usage pattens under which they are used. Since the RM spec is silent on

algorithm used to determine when (and how many) Sequences are used we need

to be careful about adding things to the spec that would restrict the

impl's choices. Above we talk about a single Sequence spanning multiple

endpoints, but going the other direction there may be RM processors that

choose to group messages destined to the same endpoint under one Sequence.

In essence what we're talking about grouping based on wsa:To. This proposal

would not allow for this type of processing model because all wsa:To values

would be the WSA Anon URI.

Doug D: There is a problem in grouping messages per endpoint. The RMS has opportunity to make grouping choice, which is lost with Microsoft proposal. Some chices are removed by the Microsoft proposal

Paul F: that choice was never in our requirements, it is something we are silent on. To say it is a requirment to judge these two specs on is not correct.

There was extended discussion on Doug’s message grouping requirement.

Dave O: Doug D is allowed to use features in ways which are not specified in the spec.

Paul C: we need to clarify the list of questions to resolve this issue.

Umit: the question is whether these undefined uses will facillitate interoperability. For whom is each uses case important. We should not be overly restrictive.

Paul C: We should try to get the right set of questions. How much extensibility exists is an important question.

Umit: I think this is an important use case which should not be restricted under umbrella of interoperability.

Dave O: Maybe a scenario which shows a flow which is no longer allowed with Micosoft proposal would crystalize the point.

7.4 PR009 "Duplicate Elimination" and "Message Ordering"

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i009

7.5 PR013 SequenceAcknowledgement protocol response for AcksTo = wsa:anonymous

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i013

agreed to defer, same as issue 12.

7.6 PR014 Composition with WS-Addressing

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i014

Marc G moved to close PR014 with no action, and an explanation to be sent to originator, Doug D seconded.

No oppostion issue PR014 closed with no action and explantion to author.

PR015 RMD polling

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i015

PR016 2nd Protocol Invariant, none and nack

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i016

PR019 Use of AckRequested

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i019

Marc G stated this is allowed, but should not be the only way to send acks.

Marc G moved to close with no action, and sending explanation to requestor. Doug D seconded.

No objection, Issue PR019 closed with no action and sending explantion to requestor.

7.7 Pr023

http://www.oasis-open.org/archives/ws-rx/200611/msg00150.html

I believe we discussed this on a call and I had an outstanding action to come back to the TC on why I thought this was so.

Currently the spec defines this as a Sender fault, so I won’t talk to that. The reason it should also be a receiver fault is that there may be times when the RMD that receives the CS message may simply be incapable of initiating a new sequence. For example the RMD may have no more capacity to process a request for an additional sequence. Therefore if the same CS message is resent later it may be accepted making Sender the wrong code in that instance.

From: Marc Goodner [mailto:mgoodner@microsoft.com]

Sent: Saturday, October 21, 2006 12:12 PM

To: ws-rx@lists.oasis-open.org

Subject: [ws-rx] New Issue: CreateSequenceRefused fault should apply to sender and receiver

In section 4.6 the CreaetSequenceRefused fault is defined as a sender fault. This fault should apply to sender or receiver.

Marc G moved, Doug D seconded to accept Marc G proposal to resolve PR023.

No objection, PR023 closed with Marc G proposal

8 Any other business

Meeting ran out of time at 5:30 PM eastern time

ws-rx message