Prelim Minutes of OASIS WS-RX Teleconference

Oct 5, 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 agenda

3) Approval of previous minutes

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

(please make comments - these are draft minutes)

4) Sponsorship of calls

5) AI review

6) Report from the Implementation SC

7) Discussion of PR issues

PR003 WS-Addressing comment/question related to WS-RM MakeConnection

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

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

8) AOB

No objections

3 Approval of the 9/28 Minutes;

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

Paul C moved to approved 9/28 minutes, Chris F seconded.

§ No objections, minutes of 9/28 approved.

4 Sponsorship of Calls

Microsoft volunteered for next meeting, in two weeks.

Adobe volunteered to sponsor the following call, in 4 weeks.

BEA volunteered to sponsor the following call.

Nortel volunteered to sponsor the following call.

5 AI Review

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

#0110: Dug to put together proposal for PR002

Owner: Doug Davis

Status: Now closed

Assigned: 2006-10-05

Due: ---

Closed by proposal from Chris F, 11:27 AM.

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

Owner: Paul Fremantle

Status: Still Open

Assigned: 2006-10-05

Due: ---

Paul F has asked OASIS staff how to do this. He has not yet received a response.

Bob F: we could have a w3c meeting with invited guests.

Jeff M: W3C could sponsor an ad hoc meeting.

Tom R: why not just use shuttle diplomacy, give the large overlap of membership.

Paul F: Bob and I discussed the potential need for a meeting in two weeks time, if each group could not solve its own issues.

6 Report from the Implementation SC

Paul F: there are endpoints ws03, Microsoft, and oracle. So far retesting scenarios from previous interop. It is making progress.

Marc G: as far as phase 2 scenarios, there has been progress on make connection sequenceID form.

Paul F: no endpoints yet from IBM, SUN, Oracle, and SAP.

Eric: Oracle will have its endpoint up soon.

7 Discussion of PR issues

7.1 PR003 WS-Addressing comment/question related to WS-RM MakeConnection

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

Chris F email at: http://www.oasis-open.org/archives/ws-rx/200610/msg00007.html

I am sending this proposed change on behalf of Doug, who is presently some 35k feet above the Atlantic.

See sections 3.10 and also Appendix B WSDL for the change mark-up.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295

wsrm-1.1-spec-cd-04-pr002.odt

wsrm-1.1-spec-cd-04-pr002.pdf

Chris F read the changes to 3.10 proposed.

Anish: These are good things. Issue pr002 states two things:

1) Need to clarify that make connection appears in body

2) minor editorial, “no soap envelopes” needs to be made singular

Chris F: this text is to resolve Jonathan’s concerns.

Jacqeus: two comments:

1) when you read current text, it is not clear as to where make connection should appear. Needs to be clarified that it is in soap:body

2) On Chris F email, the style could use brush up. Do not need to make assumption on intelligence of reader. I would not insist on the one-way operation behaviour. We do not need to be reminded that it is a one-way operation.

Marc G: can you ignore a wsa:replyTo?

Chris F: WS A does not say anything about that. It is not a response message, since it is a one way message.

Marc G raised detailed issues on valid http responses.

Chris F: it is a one way operation, as a message which is in the response flow of the http connection which are related, however there is no response message.

Marc G: 202 with a header.

Chris F: header of body is not issue, it is not a response message.

Discussion ensued.

Chris F: 202 is not disallowed from carrying entity body.

Paul F: we discussed this for piggyback acks already.

Marc G: I want to clarify the expectations here.

Paul F: I will write up a note on this, but we already send acks on 202 http response.

Paul F: I do not think we are clear enough. It would be better to effectively to say make connection message is one way , but it is unclear that a message might come back on the http response. I could take an action to write some clarifying text.

Anish: xmlP and wsA have a 202 binding. There is no contraction on igoring wsa:replyTo. The only place there is restriction is in the wsdl binding. Req/resp mep has to use replyto/faultTo to figure out where response or fault goes. Since this is modeled as one way at wsdl level, there is no wsdl response or fault. No problem with compostion with wsa.

Marc G: re reply to: the current interop scenarios have replyTo defined within them. The has been no discussion in interop SC re the replyTo behviours. We need to be concerned with implementers reaction to such changes.

Paul F: bug: because this is one way it does not need reply to. It is wrong to put something in interop scenario which would be ignored.

Discussion of scenario 3.2 and 3.1. (not related)

Jacques: I do not feel comfortable not using reply to in make connection request. It works as a model.

Tom R: but make connection has same addressing info in its body elements as what would go on reply to. Such redundancy seems “odd”

Anish: I would like to avoid this redundancy as well. I do not see what existing implementations would have a problem . I dislike a reply to on make connection message, since we say it is a one way message exchange pattern. Sticking in a reply to does not make sense. Make connection allows things to flow back so having reply to does not add anything.

Paul F: I agree with Anish. The existing implementations handle a one way with no reply to, returning a 202 as response to one way. It exists in all stacks that passed interop. We discussed what kind o relates to header would there be in this “response” message. There could be two relates two, one for earlier request, other for make connection. We did not want that, and realized no neeed for the make connection to be two way message at that level. We wanted the back channel to be for any pending soap message request. It is not a reply to the make connection itself. Having a replyTo would be counter productive.

Jacques: my main intent is generate sufficient discussion. I need to go back to my team to discuss these implementation details. Regarding relates to in wsa: the spec does not make explicit connection between relates to and reply to. Relates to can point at anything, and does not depend on reply to. However we allow a reply to in make connection, we need to know what happens if there is a contradiction between the body of make connection and the replyTo value.

Paul F: I agree the proposal needs more work. Relates to is legal, however we thought the one way approach would simplify. We could clarify this text to help

Bob F: Whether or not reply to is processed, the spec says that it is either specified as non anon uri, or it is specified as none, it defaults to anonymous. Concerning relationships being domain specific, there are a number of different proposals on how to get this information across.

Tom: we should clarify what happens if both the body value and the reply to are present and different values in the make connection.

Anish: If reply to is not relevant it is not relevant. So it does not matter since it is not relevant. If you put reply To on oneway message, it is not relevant at wsdl level meps. What are the ones that we used. MEPs on a message that are not relevant to make connection ,will not be used in the processing of the make connection message. A reply to would not change anything on how the make connection is processed. ReplyTo is unused by make connection, and that is all we have to say.

Chris F: Bob’s note on ws addressing about cr33 has initiated discussion. What is in the reply to of the make connection does not matter, since it is one way the reply to will be ignored. This is an idea to kick around regarding the use of anonymous. Need to identify which endpoint connection originated from.

Paul C: The concept of reply to being ignored seems strange. It is optional in wsa and overrides the default value. If you generate a reply, it states where it should be going. This second bullet in message is trying to say the rules of ws addressing 3.4 formulating a reply message are not used. The reply to is never ignored, however because there is not reply message, section 3.4 is never used to send a reply message. Thus the reply to has no impact, if the response procedures are not used.

Paul C: the second bullet about the message could be clarified.

Paul F: I think we need further work on this proposal. We need further email discussion. I anyone willing to propose new text for discussion.

Paul C: I would like to propose a replacement for bullet 2 of the proposal.

Paul F: I suggest we continue on the email list on this issue.

Clarification on which issue this is. Agreed that this discussion was on PR003 rather than PR002.

Chris F: last week we agreed with editorial changes from Jonathan, and agreed to make changes to the existing text. Thus this is issue 2.

Paul F: issue 3 is the problem, the minutes were inappropriate. the action item was recorded wrong.

Agreed that this discussion is on issue 3.

7.2 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

Bob F: there is a discussion going on in the WS addressing group. We are trying to abstract what problem is being solved. We are concerned about what the actual issues are, There could be more than one. The email is the intent to summarize.

Tom: The soap binding spec 3.1.2 seems to imply that wsa anonymous is for use on the single response to the particular request. This could make the proposal of using wsa:anon with queueID ref parm to determine when back channel is uses for replyTo invalid. We need to make sure we do not disagree with wsa Soap binding section 3.1.2.

Bob F: the ws addressing group has been refining its interpretation of this text.

Paul F: anonymous means anonymous. The client is expecting a response back, and the server has best effort to get response back right then. A system which always waits is not really conformant. Adding ref parms to the request does not make difference, if it can send right away it should. The difference is what happens if it cannot do it right away.

Tom R: so Paul F is trying to add additional semanitics with queue id for error conditions.

Paul F: that is my interpretation. If an http socket dies, it will not send the response right away.

Tom R: this is a new way of thinking about this for me, I need time to discussion further.

Jacques: The replyTo is talking about something different than the make connection pull. We need to clarify this text. We need to clarify if what is returned from make connection is a wsa: response at all.

Chris F: in case on anon as replyTo in request message, and there is an error condition it does not disobey addressing. If it is known there is a long tme for response where do I tell it to go.

Paul F: timing is relative. Nothing says an http connection cannot be a month long.

Chris F: If I know I am sending a wsdl request response with a single http connection I am not expection the response on the reply to. When the response is ready it will come on the backchannel identified by the URI, and that is different than anonymous.

Paul F: If I know is may timeout, I compose it with wsrm to cover the cases when the initial response times out. We are not inventing new resources, but are composing with existing services. Your model is about changing underlying semaincts.

Discussion on rm anon vs wsa:anon semantics.

Paul F: I would like wsrm use of anon to be the same , with additions to allow composabilitiy.

Paul C: I posted my recommendation for a change to bullet 2.

8 AOB

Meeting ran out of time at 5:30 PM EDT.

ws-rx message