Prelim Minutes of OASIS WS-RX Teleconference

Nov 02, 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 Oct 26, 2006 meeting minutes

4) AI Review

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

5) Report from the Implementation SC

6) Sponsorship of future calls

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

PR022 RMD cannot detect some incomplete Sequences

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

PR009 "Duplicate Elimination" and "Message Ordering"

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

PR010 Can AckRequested be sent independently or not

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

PR011 Editorial issues from eBusinss Asia Committee

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

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

7) Any other business

Doug D: asked to defer Pr001 until next week, since the proposal was new from Marc G.

Paul C: several have conflict with policy next week. We should make progress this week.

Umit: I will not be available next week.

Tom: suggested postponing next week meeting. Both WS Policy and WS-TX are meeting next week.

Paul C: we should discuss somewhat today, and then discuss two weeks later.

Marc G: we need to make progress on this.

Doug D: I do not mind discussion, however I reserve time for further review.

Paul F: I suggest we discuss this, Marc G can take us thru changes on call, if we do not want to vote, we can deal with that at the time.

Paul F: I suggested two new issues this week, after public review. I suggest we have a new issues list, and add item in agenda for accepting new issues.

Paul C: is not everything a public review comment after the public review commences

Sanjay: if we have an issue we need to deal with it, however we can view it as member input.

Paul C: I suggest we move into agenda, and suggest other process issues on the email.

Paul F: we can go with agenda as is.

Doug D: can we move PR 10 and 11 up?

Paul F: I think it is more important to make progress on pr001, I would prefer to keep the agenda as is.

3 Approval of the 10/26 Minutes;

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

Tom moved to approv 10/26 minutes as on email, Paul C seconded.

§ No objections, minutes of 10/26 approved.

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: Open still pending

Assigned: 2006-10-26

Due: ---

5 Report from the Implementation SC

Paul F: there is progress, however the target of next Monday will not be reached.

People are using Doug’s page to keep status up to date.

6 Sponsorship of future calls

Bob F: Hitachi can do a couple of calls

Gil: BEA can do a couple of calls.

Paul K: Nortel is willing to do a couple of calls

7 Discussion of PR Issues

7.1 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

Marc G latest proposal: http://www.oasis-open.org/archives/ws-rx/200611/msg00018.html

Marc G: This revision uses a new makeConnection EPR, to avoid concerns of using the acksTo epr. There were also some corrections on the details of the fault semantics. This is in response to some requests from members to clarify.

Doug D: can you elaborate on how makeconnectionEPR is used, on both request and response.

Marc G: it is done just as in the current text.

Tom: this seems to be getting close to a mechanism which is more specific to ws-rm.

Doug D: I would like to go thru my earlier objections to see if they still apply.

Jacques: I agree that it is important to go thru the requirement items raised by Doug D.

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

Marc,

comments inline. Overall, I think you need to show a lot of concrete sample message flows to prove that your proposal is not only better than what's in the spec but can even work at all because most of your answers don't address the issues I've mentioned.

Another issue was realized the other day, so I might as well mention it here:

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? This proposal is based on the MC being sent to the AcksTo EPR but the AcksTo EPR is on the wrong side of the connection for this sequence. This proposal doesn't address how these Fault messages can be delivered.

The current spec doesn't have this issue because the AcksTo EPR can use the same RManonURI as the other EPRs - which means a single MC can be used to pull back any message that needs to be sent - whether its an RM-enabled response or a SeqFault for the outbound sequence.

-Doug

Marc G: why do you want to poll for faults?

Doug D: are not faults supposed to be send?

Marc G: why would it have not been sent on back channel?

Doug D: there may be no back channel.

Doug D: acks to may be different from replyto. I am not sure how that would work.

Marc G: I do not understand your concerns about faults. All the proposals have the same concerns.

Doug D: the current proposal allows the new anonymus with id in the acks to epr.

Marc G: this is not clearly defined in the spec currently.

Marc G: there is no text about using rm:anon as acks:to EPR. The current text has an unclear model. That is why I put together the proposal I did. I do not see problems in faults with my proposal.

Doug D: The text alllows for multiple eprs in the acksTo.

Marc G: sounds like another issure to be raised around make connection.

Marc G: using this epr in acks to is an unexpected usage. My proposal addresses this.

Doug D: we could add clarifications, including sequence diagrams to the text.

Gil: you are saying an anon client has outbound sequence to service and an inbouns sequence back. There could be a sequence fault that the client needs to get back. Why cannot it go on the back channel?

Doug D: If the message being sent causing sequence fault, if it had reply to, but acks to was different, what are the ref parms on the fault message. Using acks to epr for faults violates addressing.

Paul F: this also applies withoug makeConnection. There can be an anonymous reply to different than anonymous acks to.

Doug D: the answer to that might be use of make conection. This migh be a bigger problem

Paul F: if I want the fault to come back on the backchannel, I would not to poll on sequence fault. Either acks to = reply to , or fault comes back to reply to in anon case. We need to raise this as a new separate issue.

Chris F: there is a wsa:faultsTo for this case. Some customers want a fault logging epr. Assuming the fault is on back channel is not always appropriate. You are excliding a valid set of use cases, in alignment with ws-addressing.

Paul F: if the server cannot connect to a fault epr, that sequence fault might just be dropped.

Paul C: Doug suggested we go thru Marc’s prpoposal, to ask questions. Now we are talking about some new issue. Is it not better to rely on someone filing a new issue.

Paul F: are willing to accept a new issue

Doug D: the current spec handles this situation in marc’s proposal.

Paul F: we added make connection to support the two way anonymous case.

Martin C: we can use the issue process .

Continuing on issues with pr001:

Doug D: the current text has solutions for Marc’s use case.

Paul F: the current text is not clear. I will raise an issue on this.

Doug D: whether the current text has problems with ws-addressing. I do not believe we have a proboem. The wsdl marker cannot be sent to prohibited, with the anonymous uri. It can be defined as optional. Which parts do not work in the current spec.

Marc G: It was this group that suggested to wsa that other orgs and define new anonymous uris. What I find erroneous is that the current spec does not define how make connection is to beused. Many of Doug’s suggested uses do not involve wsrm headers.

Doug D: what is actually broken about the current spec.

There was extended discussion.

Paul F cannot see ability to take vote. The discussion is not much what has been on the email list.

Chris F: what is the vote to be on. This is a new proposal, which is not necessary. It is not broken

Paul C: I would like to ask what the TC thinks. I would like an electronic vote.

Chris F: what about a proposal to close without action.

Marc G: I would move to have the chair start an electronic vote on message 18 from this month’s archive., Seconded by Paul C.

Doug D: I had isssues on this proposal. My concerns have not been properly discussed in my opinion. Marc G has made a claim that something is broken in our spec. I have not heard technical arguments about things being broken in the spec.

Dave O: I was not hearing technical arguments either way, there was just procedural issues.

Martin C: I find it strange to set up a ballot and also to do vote on proposal at same time. I think more discussion is required.

Paul F: If the TC is still in motion in their positions, we need to know this. Are there people who need more time to discuss.

Chris F: I speak against this motion, since we have not addressed the technical issues involved. Until we go thru the proposal to address technical issues, we should not vote.

Chris F: such a change as proposed by Marc would require a second public review. This is a substantiive change, affecting on our ability to deliver in the near term. We should be sure we are solving a problem.

Umit: I am confused about the problem we are solving and why we are solving it that way. Is there is anything else which can solve this problem. I get the sense that people have different sets of use cases, or did not agree with the use cases on the table originally. I am agains the motion on the floor.

Paul F we ran out of time. We will continue discussion next week.

Meeting closed at 5:30 PM eastern time.

ws-rx message