Draft minutes WS-RX 2006-04-04

2006-05-04

Chair: Sanjay

Agenda accepted without objection

Minutes of 2006-04-27 call were approved without objections

AI 99 – Doug: AI to remain open

New Issues –

1 - ChrisF:

Change word request with word messages in re-try language

New issue was accepted without objection as issue number 118.

Motion made seconded and accepted without objection to accept proposed resolution

2 - Doug:

Proposal to define how to determine when piggy-backing is permissible:

No objections to accepting as a new issue and will be issue number 119

Discussion of issues

Topic: issue 113 http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i113

Jacques:

Several proposed “small” changes to the state table. Proposal in http://lists.oasis-open.org/archives/ws-rx/200604/msg00026.html

Jacques explains the contents of his proposal…

MarcG: concerned about splitting the tables or splitting the cells and the impact on clarity

…disputes proposal to move state change on sequence expiry from terminated to closed

Jacques:

Has not looked back in the spec on this change of the next state on sequence expiry

Has added one line , an event to move to the connected state based on an offer.

Each update is small

Bob: proposes a subset of folks to work on state table revision.

Tom Rutt & bob volunteered to work on state table revisions

Topic: Issue 114 http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i114

New proposal 2 http://lists.oasis-open.org/archives/ws-rx/200605/msg00018.html

MarcG moves to accept above proposal, seconded and accepted without objection

Topic: issue 89 Anonymous URI http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i089

PaulF’s new proposal 6 http://lists.oasis-open.org/archives/ws-rx/200605/msg00023.html

PaulF would like this as well as his previous proposal considered by the TC http://lists.oasis-open.org/archives/ws-rx/200604/msg00022.html

New proposal was designed to address what Paul considered to be the most common use case.

Sanjay: Are you ok with going ahead with the minimalist proposal?

PaulF: yes

Chair: Are all 3 proposals still on the table.

MarcG: I do not think that my proposal is on the table anymore.

DoubB: Funny, I would have voted in favor of that one.

Chair: ok to limit discussion today to two proposals?

Martin: procedurally, unless there is a motion, this is nonesese

MarcG: Whole issue makes me nervous because it steps on the protocol layer, however with PaulF’s minimalist approach

… scoped down narrowly to RM, I am ready to consider PaulF’s minimalist proposal and therefore I move to accept the minimalist proposal. Bob’s second

Doug: Given the scope of the issue, I am uncomfortable with voting on any proposal at such short notice.

… I don’t believe that PaulF’s proposal does not some important MEPs and important use cases and a small subset of RM use cases.

Jacques: Still worth it to spend one more week on consideration due to considerable exchange of email over te past few days.

Paul’s proposal has improved a lot, Doug’s proposal is wide-reaching and general. Technically I like both, but I do not feel like picking one or the other today.

Matt: I do not think that is helpful to have a vote now, since both proposals are incomplete. Acceptance of either proposal will spawn more issues. At the moment I prefer Dug’s, but Paul’s is incomplete.

PaulF: I made this proposal based on WSO2 use cases with clients doing an in-multi-out pattern. That is what I based on the minimalist proposal. If the 4.2 optimization is important to the TC, then I would be happy to add that back in to the proposal.

…I am kind of concerned about the idea that this is changing the protocol. Offer has been in the spec since it was submitted, I do not consider this to be a fundamental change. If a client is anonymous, then it must initiate a connection.

DaveO: proposal arrived only about 24 hours ago, so it is too soon to vote. BEA would like something in this area, but it may need review and .

Motion to table, seconded several time, passed without objections.

TomR: Jacque’s problem seems to be very subtle concerning determining the source of the offer.

PaulF: Text uses the word MAY a lot. One of the things not discussed yet in this TC is how one assigned messages to sequences.

…I am happy to have some words in the spec so that the client may put an id in the header. Interop scenarios so far have been limited to common use cases.

…Is reliable out only with an client something we intend to support or not?

DougD: You seem to think of the out only case as rare. In my opinion reliable notifications are key. It is unclear to me how PaulF’s proposal has now way of knowing when to send an offer, or how often to send an offer. I do not understand how the proposal can work.

PaulF: The reliable out only case is more likely in an addressable environment. It might be done via offering a sequence to the server. The server would need to decide how to allocate messages to these offered sequence. I think there is a more generic problem of how clients unreliably subscribe with anonymous endpoints. I don’t think that this is within the scope of this TC since it a more general problem.

DougD:You talk about your proposal handling reliable discussions. But I do not see how to do it and you are making it up off the cuff.

PaulF: bollocks

MarcG: move on to the next issue nobody is ready to discuss.

DougB: I want to formally get the feeling of the TC about MarcG’s proposal therefore I move to accept his most recent proposal to meet these requirements. SteffanB seconds. http://lists.oasis-open.org/archives/ws-rx/200604/msg00114.html

Chair: Please focus discussion on the motion on the table.

DaveO: Question concerning PaulF’s proposal related to WS-Addressing properties that seem to be omitted from the proposal. RelatesTo, messageID and so forth.

PaulF:I will draft a note to answer DaveO’s questions

…I am speaking against the motion since the TC seemed interested in enabling these use cases at the last F2F

Martin: I agree with Paul, since I think that a solution be found and speak against the proposal on the floor, however I think that the other proposals

Matt:Motion to table

Martin&PaulF: object to table

Matt withdraws this motion to table

TomR:having to wait for something like WS-Transfer for something that is real important to us, I strongly speak against the proposal.

DaveO: speaks against the proposal. The will of the TC is to solve the problem. I would like to consider using WS-Transfer, but there are issues related to the minting of the EPR. I am considering how WS-Transfer’s issues may .

Sanjay: speaks against the motion

DougB:Doug would like to see DaveO’s WS-Transfer proposal. The main reason that this proposal is a good one is that it allows composition with future general solutions. Other proposals seem to close off composition which is one of the core tenant of WS-*

Jacques: I don’t think that we need to depend on a future spec to complete reliable

PaulF: Calls the question

Chair:Any objections to calling the question? No

Chair: any objection to accepting the motion?

YES

Chair: Roll call vote:

Yes-10;No-13

Motion fails.

ws-rx message