Prelim Minutes of WSRX TC telcon 3/2/06

ws-rx message

Subject: Prelim Minutes of WSRX TC telcon 3/2/06

From: "Gilbert Pilz" <Gilbert.Pilz@bea.com>

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

Date: Thu, 2 Mar 2006 14:53:25 -0800

Prelim Minutes are attached.

Please provide corrections to the list before Next Monday.

- gp

1:11PM - Agenda Approved

1:11PM - Approval of the 2/23/2006 minutes; moved and approved by unanimous consent.

1:12PM - Action Items

Paul suggests that anyone that feels strongly about the ASIS requirements should send a note.

1:13PM - CD III Ballots

<BALLOT"WSRMP CD III" carries; http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/16843/wsrmp-1.1-spec-wd-06.pdf) be agreed as WSRMP CD 03>

Paul C & Sanjay: All new proposals should be based on CD 03. CD 03 forms the basis of the March interop.

1:15PM Raleigh F2F Planning

Sanjay: Need dial-in sponsorship.

Gil: BEA

Paul Knight: Nortel

Paul: Maybe we should get someone who is not traveling to the F2F to sponsor a line?

Doug: People need to respond to the ballot on F2F attendance. IBM needs this to figure out meals, etc.

1:18PM New issues since last conf-call

Marc: (from WebChat)

proposed-01 new state tables (Dug) http://lists.oasis-open.org/archives/ws-rx/200602/msg00261.html

proposed-02 extensibility of assertion (Marc) http://lists.oasis-open.org/archives/ws-rx/200602/msg00262.html

Doug: (moves to accept proposal as is)

Marc: (seconds)

proposed-03 sequence and non seq faults (Gil) http://lists.oasis-open.org/archives/ws-rx/200603/msg00008.html

Paul: Did Gil propose a solution.?

Gil: No.

Doug: Gil, you should reference the latest WD when working on this.

proposed-04 relate faults to seq in SOAP 1.1 (Gil) http://lists.oasis-open.org/archives/ws-rx/200603/msg00009.html

proposed-05 language for fault strings (Matt) http://lists.oasis-open.org/archives/ws-rx/200603/msg00015.html

Doug: (moves to accept proposal)

Gil: (seconds)

proposed-06 close instead of terminate (PaulF) http://lists.oasis-open.org/archives/ws-rx/200603/msg00019.html

Paul: (reviews). This does not change the state table of affect the protocol in any way.

Anish: Why would I use CloseSequence if all the messages have been delivered and the Final has been sent and I just want to stop using the sequence?

Paul: The question is "Does the RMS know that all the messages have been recieved."? This applies only to the RMD

Anish: Oh. Nevermind

Tom Rutt: This is mainly an editorial point. Is "recommended" an RFC2119 defined term? (missed some points - feel free to revise Tom)

Paul: (agrees with Tom on replacing "recommended" with SHOULD)

Chris: Is there a motion to resolve this?

<ACCEPT: proposed issue accepted as a new issue>

Matt: (Moves to accepted amended proposal)

Bob: Would like to make sure that this change is based off a version of the document that incorporates the resolution of i0xx?

Doug: I believe that change is in wd-10.

proposal

"In the case where the RM Destination wishes to discontinue use of a sequence it SHOULD close the sequence."

Paul C: Does the normative text say why the RMD would want to do this?

Paul F: It says "it may wish to" but it doesn't say why.

Paul C: I think it would be helpful if there was some indication of why the RMD may want to do this.

Chris: It got confused.

(someone): This sounds like a new issue.

Paul C: If someone raises that as a proposed issue, I will support it.

Marc: How does this related to the text at line 368?

Paul F: I'd be happy to go away and work on this proposal. I wasn't prepared to try and resolve this issue on today's call.

Marc: There is a discrepancy between line 368 and the proposed change.

Paul F: The above line (368) basically calls out the need to close/terminate a sequence. The proposed change is simply recommending the mechanism for doing this.

Paul C: We need this written down.

<ACTION ITEM> Paul F to write up a more detailed proposal to this issue.

1:41PM - i021

Sanjay: (references his latest proposal; yields floor to Chris to describe his changes to the proposal)

http://lists.oasis-open.org/archives/ws-rx/200603/msg00000.html

Chris F: (discusses his concerns and references)

http://lists.oasis-open.org/archives/ws-rx/200603/msg00000.html

Ultimately Message Policy Subject needs to be made OPTIONAL (in the RFC2119).

Anish: Isn't all of WS-RMP optional?

Chris F: That's true, but it needs to be made clear that can't expect Message Policy Subject behavior from any endpoint.

Anish: I agree it should be RFC2119 OPTIONAL but I still don't understand your concerns. If you mark a message as needing RM, the port needs to support RM.

Chris: I agree and that's why my proposal decorates the port. I can understand the desire to have more fine-grained policy, but most people don't do reliability on a message basis.

Anish: In your new email, you would want the support for message policy scope to be optional? The other text about decorating a port would not be part of your propsal?

Chris: Yes.

Anish: That would be a good compromise.

(someone): What is the compromise?

Anish: Take Sanjay's assertion and add text to make support for message policy subject to be optional.

Sanjay: (missed)

Ashok: Only message policy scope is optional?

Tom: Will this cause some confusion that if you apply it at the endpoint it means both input and output?

Chris: No, this is not what I want but the group has made it clear that this is not the way it wants to go.

Marc: (missed)

Chris: No, I'm talking about the other proposal which was basically a reiteration of Doug's proposal. RMAssertion applies only to incoming messages. If you want outgoing messages than you need to put policy in an EPR that you supply to the destination. (missed Chris' explanation of how this idea was shot down).

Marc: I agree (not with the previous proposal). I like the compromise on the table but I don't like the fact that an RMAssertion attached to an endpoint applies to both input and output messages.

Anish: Which proposal do you like?

Marc: http://lists.oasis-open.org/archives/ws-rx/200603/msg00000.html

Gil: Optional means the AS/RMS needs to be ready to handle a WSDL with Endpoint Policy Subject.

Sanjay: Agree. Optional raises interoperability concerns.

Anish: This is a compromise. I don't really like it but I really don't like the proposal in msg0000.html.

Chris F: If you read my proposal carefully it says its optional. That means its optional for all the messages.

Anish: (missed)

Chris F: If you want to be interoperable at the broadest level you have to accept that there may be endpoints that can't deal with message level.

Anish: Nobody is forcing an endpoint to do anything.

Chris F: I'm not talking about the endpoint that hosts the WSDL. Can we say that an endpoint that attaches RM policy to and endpoint must support RM. Can we agree to that?

Anish: That's only true for the messages to which the policy is attached.

Chris F: Attaching an RM policy to a particular node says nothing about RM support at other nodes.

(queue breaks down - thread untraceable)

Jeff: Chris I don't understand what you are saying.

Chris: All I'm saying is that there is an RM engine at the end of that endpoint.

Jeff: It might be for the message with RM policy, but not for the messages w/out RM policy endpoint.

Chris: I refuse to implement that.

Sanjay: Chris, you are saying that if RM policy is attached for 3 out of 4 messages in a endpoint then it should implicitly be supported for the other message.

Chris: (lost thread)

Tom: I hope you are not saying that if an endpoint supports RM that it must be a full RMD and RMS. I want to make sure that I can deploy something that is solely an RMD.

Chris F: You decorate individual messages and then mark the endpoint as supporting RM. Input messages can be marked as requiring RM and the output messages can be left optional so in the case where you don't have an RMS at the endpoint you don't get WS-RM semantic on the outbound message and that's ok.

(Tom and Chris): (more back and forth)

Tom: I need to see better wording.

Paul F: I agree with Tom. It makes sense to me to have a situation where you only deploy an RMD and not an RMS. I agree with what Chris is saying. If RM is enabled on a message then it is ok for the RMS to send any of the other messages in that same endpoint reliably.

Chris F: That's what I'm asking for.

Sanjay: I see the desire to have message policy subject that provides fine grained control. Chris' proposal does allow that. For sources that don't process WSDL, they would like the ability to send messages wholesale using RM and not get a fault.

Chris F: Would it help if there were some narrative around what this is intended to achieve?

Tom: That would help.

Chris F: I would be willing to take this back and work on it some more.

Paul C: +1

Anish: The big problem I have with this proposal is that it doesn't allow me to say "RM required for inbound but all bets off for outbound".

Chris F: It does. Mark "required=false" on all input messages. The lack of "required" on outbound messages means the destination should be ok if it can't apply RM to those messages.

Anish: But this still means that RM is supported for outbound messages.

Chris F: The source does not need to provide an RMD. RM on outbound is optional and if the infrastructure is not there, then no big deal.

(queue breaks down - thread untraceable)

Sanjay: Can we override the meaning of <wsp:Optional>?

Chris F: Policy doesn't say anything about that.

Ashok: Policy says that you "may or may not" obey those policy assertions.

Anish: At runtime you need to be ready to handle this may or may not. This requires that the client has to be ready to support RM on outbound messages or fail.

Sanjay: Does this need some more work?

Chris F: It satisfies the requirements.

Anish: It doesn't satisfy my requirements.

Gil: I think there is text that can be added to Chris' proposal that will satisfy Anish's requirements.

Anish: "Optional" in Policy doesn't mean that.

Gil: Can we override?

Ashok: No.

(Chris & Anish): (back and forth on the meaning of "optional" in Policy)

Chris: Maybe we need a way of indicating that RM is *not* supported.

Paul F: I think we've got the closest we've ever got to resolving this. We finally agree on the behavior we want. (recaps requirements). I suggest we write down the behavior that we want. If WS-Policy can't help us then we need to go our own way to define what we mean.

Anish: I'm not sure I agree with the requirements that Paul outlined. I think that would make both of us happy would be two assertions: one for input and one for output.

Sanjay: How would the two assertions be different. One says RM not supported?

Anish: No, this builds on Gil's proposal. One assertion for input and one for output.

Sanjay: The directionality of the messages is already in the definition of operation. Why do you need different assertions?

Anish: Because if you don't, when you attach the assertion at the port suddenly it applies to all the outbound message in the port.

Paul C: I like where Chris is going?

Doug: How close is your idea to Gil's proposal?

Anish: The difference is now that you have message scope plus Chris' ammendment that, if you put it on a message, you have to put in on the port with "optional=true"

Sanjay: Anish, can you put together a revised proposal?

Marc: What is the current proposal?

Stefan: Just to help the rest of us on all these proposals I would like to hear from each proposer what do they think the client needs to be prepared to do?

Chris: In my world I envision the scenario you described. There is no obligation on the service consumer to support an RMD. If the service provider can't establish a sequence to carry the outbound messages then it can't do RM which is ok because it's optional.

Anish: I interpret "optional" quite differently.

Chris: I said this had to do with the service provider trying to establish a sequence in the optional direction.

Paul C: I wanted to support Paul Freemantle's suggestion. Too many people are moving towards concrete proposal without defining the semantics they want to support. We in the silent majority often can't see through the detailed expression of the ideas to see what the goal is.

Chris: I think I articulated in my email last week the semantics I want.

Paul C: So the challenge to others is to define what they want. Is that in msg0000.html?

Chris: No, it's in another email.

Paul C: Encourages everyone to link the desired behavior with the concrete proposal.

Sanjay: It seems both sides want to support the same requirements but disagree about the expression.

Tom: I thought that Chris was going to provide extra text in the proposal. Are all proposals going to carry sermantics?

Chris: Yes.

Paul C: Chris agreed to provide references to the semantic explanation. You're asking for semantic explanations in the actual proposals.

Sanjay: Anish to take AI to describe desired semantics.

2:29PM

Sanjay: Moving on to other business.

Chris F: Doug remind people about non-US citizen

Doug: Anybody who is a citizen of (reference email for countries). Unclear about citizens of other countries. Recommend carrying your passport.

all: (general discussion)

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.