Prelim Minutes of OASIS WS-RX Teleconference

Dec 14, 2006

Start Time:4:00 PM Eastern Daylight Time

Sanjay 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 Dec 7, 2006 meeting minutes

Draft minutes http://lists.oasis-open.org/archives/ws-rx/200612/msg00009.html

4) AI Review

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

5) New issues

6) Discussion of PR Issues

a> 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

b> PR026 Retransmission

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

c> PR033 back-channel not defined

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

d> PR035 Delivery Assurance

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

e> PR009 "Duplicate Elimination" and "Message Ordering"

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

f> PR020 Message ordering and duplication

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

g> PR021 Piggy-backing problematic

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

h> PR018 Piggyback message combinations

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

i> PR022 RMD cannot detect some incomplete Sequences

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

j> PR007 RM Destination lacks a mechanism for cleanly terminating inbound sequences

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

7) Any other business

No comments, agenda approved.

1 Approval of the 12/07 Minutes;

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21521/wsrxMinutes-120706.htm

Tom moved to approve 12/07 minutes, Paul K seconded.

§ No objections, minutes of 12/07 approved.

2 AI Review

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

Report created 14 December 2006 01:33pm EST

#0113: Sanjay to follow up with Paul to create a review plan Note that there is a new ignorable attribute

Owner: Sanjay Patil

Status: Still Open

Assigned: 2006-12-07

Due: ---

#0114: Paul to talk to some of the people and find a middle ground proposal for PR26

Owner: Paul Fremantle

Status: Closed, with Matt Lovett proposal

Assigned: 2006-12-07

Due: ---

#0115: Stefan to put together concrete objections to Gil's strawman on PR007

Owner: Stefan Batres

Status: Still Open

Assigned: 2006-12-14

Due: ---

#0116: Bob and Chris to propose language for PR033

Owner: Robert Freund

Status: Done

Assigned: 2006-12-14

Due: ---

3 New issues

None

4 Discussion of PR Issues

4.1 a> 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

Doug Davis submitted email: http://www.oasis-open.org/archives/ws-rx/200612/msg00024.html

On last week's call we were asked to write up something that would describe the scope/details of the proposal we made w.r.t. moving MakeConnection into a new spec. I think the text below should cover that.

Proposal: Move MakeConnection into a new specification

Details:

Move the MakeConnection (and related portions of the RM spec) into a new specification that will be developed by the WS-RX TC. The overall scope of the TC itself will remain the same. The scope of this new specification will be limited to the development of a mechanism that will establish a transport-specific back-channel. This back-channel will be used in situations where an anonymous URI is used as the destination EPR for messages and there is no existing/appropriate back-channel available. The specification will try to address the use-cases that have be identified during the recently discussions in the WS-RX TC. These include:

- Attempt to not restrict the RM processing model choices when switching from async to sync MEPs

- Support for multiple endpoints behind a virtual RM processor

- Support for gateway scenarios (on RMS and RMD)

- Support for allowing an RMS to advertise its support for MC

- Support for allowing an RMD to advertise its intention to use MC

- Support for anonymous AcksTo (in particular for the Sequence Faults)

- Support for unreliable-in/reliable out scenarios

- Retain the notion of the RMS being the initiator of new Sequences

- Support for uniquely identifying anonymous endpoints

As this specification will compose on top of the base WS-RM specification, the base WS-RM specification's issues will be prioritize over the MC issues. The list of PR issues that this new specification will address are:

i001 WS-Addressing comment on ws-rm related to use of extended anonymous uri ws-rm design *

i015 RMD polling ws-rm, ws-rmp design

i027 Where do Sequence Faults go when the RMS is anonymous ws-rm design

i028 MakeConnection preconditions are unclear ws-rm design

i029 Opaqueness of URI identifiers not preserved by RM anon URI ws-rm design

i030 Facilities to support optional MakeConnection underspecified ws-rm design

i031 Scope of MakeConnection is unconstrained ws-rm design

thanks

-Doug

Marc G: I agree with Doug’s summary.

Marc G: I move we proceed to resolve PR001 with Doug’s proposal in email, seconded by Bob F.

Anish: I do not see that this should affect the priority of progression. I would like to see the work on both of these specs proceed in parallel. I so not think one has to be prioritized over the other.

Sanjay: we need to continue to resolve Make connection issues.

Jacques: I agree it is good to separate the Make connection. If we do it in this TC we must restrict ourselves to requirements involving Reliable messaging. We need to avoid working on a overly general solution.

Sanjay: what about the wording of Doug’s proposal.

Jacques: I would like to remain within the scope of our charter when we go forward on the split off spec.

Colleen: The TX group split off core items, and it worked well.

Martin C: We need to get both done to fulfill charter. I do not care about one or two docs, however we should have an orderly way to deal with the existing issues. Lets move forward.

Anish: The prioritization is binding tc to actions. We approve the agenda each meeting, that should suffice. I would like to remove the prioritization part.

Anish: Move to amend by removing prioritization part from Doug’s proposal, Seconded by Martin C

Marc G: we can get the core document out there quicker, since we do not have to hone the make connection issues. I think it is better to sequence the work.

Sanjay: prioritization depends on getting input contributions to evaluate. We need to assign action items to complete the work. The prioritization is not at the core of this proposal, since it is part of the normal work of this TC. I would like to focus on the splitting of documents.

Anish: I suggest the use cases MC addresses are important for RM. We might start a task force to complete the MC work in a timely manner.

Doug D: The prioritization is a statement that our customers need RM now. I think it is a slight favoritism to core RM issues.

Jacques: I understand concern of Anish. It should not be interpreted to slow down the core spec. I do have a reserve for pushing out the MC work later on might prevent us to look at cases like reliable request response. We should move forward with MC work in parallel with the core spec, to make possible reliability in response over Firewall.

Sanjay: we should determine who can do work on the spec by when. Lets postpone discussion of prioritrization.

Martin G: if we split, rm spec goes out for another public review. We work on Make connection spec before its public review. It would nice to get both to committee spec together.

Paul C: we should:

- pass the motion un amended,

- create a new task force,

- resolve remaining core issues, put out for second public review

- resolve Make connection issues.

Paul F: I propose an amendment to this motion, at the time we do this the editors create the new document, and vote on the make connection as it is today version as a committee Draft.

Martin C: I do not understand the waiting for working on Make connection.

Paul C: the public review is on rm and rm policy, during that time we can work on make connection.

Martin C: That seems fine.

Anish: the MC document has no external dependencies, so there is no need to delay it. Whether MC should be included has been voted in the affirmative twice in this TC. If we deprioritize this work, it could be seen as a separate and kill motion.

Marc G: this feature was added with a small vote margin. Taking out of core spec is the best way to work together in the TC to move forward. This will remove the controversy we have seen in the past.

Dave O: I share Anish’s concerns to avoid separate and kill. Maybe it will work out as Marc G proposes. However we need to get interoperable implementations against all required features.

Jeff M: how does moving a venue resist controversy?

Doug D: I agree that separating it out will help move things along. We can address the core stuff in a timely manner, while working out the details on the additional features of Make Connection.,

Doug O: When I see things get factored off, that is a way to split the conformance requirements for implementations, rather than technical merit.

Jeff M: There is no assurance that the second spec will ever become OASIS standard.

Jacques: considering the prioritization in Doug’s proposal, I favor the amendment from Anish. The wording of the prioritization is not precise.

From Chat:

anish: the reason i'm in the queue is: MC spec is to enable certain core RM usecases. It happens to be that MC is generally useful. But it is important to ensure that RM is composable with MC and that the MC spec does not require changes to the RM spec itself. Therefore it is important to ensure that the work goes on in parallel

Paul C: I move to call the question on the amendment, Chris F seconded.

Yes means proceed to vote, no means continue discussion

Vote on motion to call question:

20 Yes

9 No

Call of question passed.

Vote on amendment

14 Yes

11 No

5 Abstain

Ammendment to remove prioritizations passed.

Anish called question for amended motion, Chris F seconded.

No objection to call question. Vote proceeds on main motion.

Vote for main motion:

23 Yes

3 No

6 Abstain

Amended proposal is accepted to resolve PR001.

Sanjay: lets separate out the make connection text as current into its own draft spec.

Doug D: I could have this done before the next phone call.

Sanjay: that is next year.

Paul C: we need to distinguish which issues are for which document.

Action: Marc G will sort out with Chairs and editors on apportioning existing issue against the core spec and the new Make Connection spec.

4.2 b> PR026 Retransmission

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

http://lists.oasis-open.org/archives/ws-rx/200612/msg00034.html

> While the Sequence is not closed or terminated, the RM Source

> SHOULD retransmit unacknowledged messages.

Moved by Doug D, seconded by Gil to close PR026 with proposal from Sanjay.

No objection to close PR026 with Sanjay proposal.

4.3 c> PR033 back-channel not defined

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

bob: Backchannel: When the underlying transport provides a mechanism to return

a transport-protocol specific response without initiating a new connection,

we refer to this mechanism as a backchannel.

Chris F: SMTP does not have a back channel.

Paul F: In my view SMTP has a reply to, but that is not a back channel.

Chris F: the text bob quoted deals with the connection orientation of an underlying protocol. It means not to start a new transport connection.

Bob F: the definition is targeted at the Make Connection mechanism. That use case was that the reply to endpoint is not addressable. The Back channel does not apply to SMTP use cases. I believe the approach of defining the back channel to be transport capability is the way forward.

Peter N: The word back channel is only used for anonymous URI. So the description should be limited to the anonymous URI, An SMTP reply to would not be an anonymous URI.

Discussion ensued on the scope of back channel.

Anish: the definition does not require the backchannel to be able to carry a soap message. By this definition a low level small pipe ack would be considered a back channel, however it could not carry soap message.

Bob F: for Make connection to work the back channel must be able to carry a soap body.

Chris F: I do not agree that SMTP has a back channel, the smtp reply to can be spoofed, a connection return message cannot be spoofed.

Paul F: TCP has the ability to spoof addresses.

Chris F: however the connection provides integrity.

Paul F: I prefer Matt’s original definition - Backchannel: When the underlying transport provides a mechanism to return a transport-protocol specific response, we refer to this mechanism as a backchannel

Jacques: The back channel, regardless of addressability of reply endpoint, will always work. That is the primary requirement. Thus I do not like the broader definition from Paul. I prefer the inclusion of connection in the definition.

Bob F: SMTP RFC 2821 is protocol, and RFC2822 is definitions of elements that can be carried on any protocol. The restriction of the definition to a connection is crucial. SMTP does not have a connection.

Chris F: the proposed definition uses the word “transport protocol”. The definition relates to the connection orientation of the transport protocol.

Anish: I do not want people to assume that we are not using protocols other than TCP. HTTP is the level we are talking about, it always has an http response coming back.

Gil: This group does need to define back channel. The wsaRM anon uri has a strict use of back channel. However wsrm:anon has a different use of the backchannel. The definition cuts to the heart on why make connection works. The requirement that the backchannel can carry a soap message should be a necessary attribute for the back channel.

Doug D:

Dug: Backchannel: When the underlying transport provides a mechanism to return a transport-protocol specific response (with a SOAP message) without initiating a new connection, we refer to this mechanism as a backchannel.

Doug D moved to resolve issue pr033 with text above, Marc G seconded.

No objection to resolve issue pr033 with agreed definition of back channel.

4.4 d> PR035 Delivery Assurance

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

Mail from Jacques: http://lists.oasis-open.org/archives/ws-rx/200612/msg00031.html

After more discussion with issues originators: they want mostly a couple of things:

1. Definitions for the reliability assurances mentioned in the charter (At-least-once, At-most-once...) . These are informally defined in the charter but these definitions really belong in the spec, using the precise terminology introduce by the messaging model, and also referring to protocol elements. For example, there are several mentions of " message duplicate" , but no clear definition of this term (how is a message identified ? with wsa:MessageId? or by sequence ID + sequence # ? the latter is only alluded to in the 2.4 example)

Rationale: even if the support and requirement for reliability assurances is out of scope, product developers need to refer to common definitions when they decide to implement these. Their implementation will affect the design of RMD product from the start.

2. RM Policy assertions that identify these reliability assurances.

Rationale: for those implementors who have decided to implement reliability assurances, the users of their products need to be able to exchange agreements or capabilities on these. For those service providers who require or support these assurances, there needs to be an interoperable way to advertise them.

Note: clearly there may be more reliablity assurances than the minimal set mentioned in the charter - and in particular, there may be several flavors of ordered message delivery. Also different flavors of what to do in case of failure. But a minimal set is needed in a first phase.

So... sounds a bit like "deja-vu" , but note that the above proposal does NOT make any requirement on implementations, and does NOT impose that the protocol vary with the delivery assurance. Only that a core set of definitions and policy representations be present for those who choose to implement them and to share them.

Regards,

Jacques

Jacques presented his email.

Chris F sent mail: http://lists.oasis-open.org/archives/ws-rx/200612/msg00008.html

Previous to the LC draft of the WS-Policy 1.5 - Framework spec, there was no means by which

you could include an assertion that had no client impact and/or on-the-wire manifestation. All assertions

had to be both understood and would manifest themselves in the interactions between the two

parties.

However, in the LC draft, the WS-Policy WG introduced a new attribute: wsp:Ignorable, of type boolean,

that could be added to an assertion to indicate that at the policy consumer's discretion, that assertion

could be omitted from consideration in the intersetcion algorithm. Thus, a service provider that

wanted to advertise a QoS capability of the service, sich as a delivery assurance, that in fact placed

no requirements on the part of the client, such that the client could choose to ignore it if it didn't

understand that assertion. Effectively, it is a means for the service prvider to advertise in its policy

"here is an assertion, but you don't need to do anything about it, or even understand it and you can

still interoperate with me".

One of the concerns that we had previously with regards to delivery assurances (DA) was that regardless

of what DA was, or was not inforce, the protocol was exactly the same in all cases. Thus, prior to the

changes introduced in the WS-Policy LC draft, there was really no means of defining a policy assertion

that could advertise a DA and also provide a means by which the client could choose whether it

wanted to consider it in the intersection.

Given that WS-Policy now has this new feature, and given the concerns that have been raised by

FIX and others, perhaps we might consider addition of policy assertions that reflected the semantics of the DAs we previously had in the input specification, with a strong recommendation that service providers leverage the wsp:Ignorable='true' attribute to allow for a client to omit the assertion from consideration in the intersection algorithm.

e.g.

<wsrmp:ExactlyOnceDelivery wsrmp:InOrder='true|false' wsp:Ignorable='true'/>

<wsrmp:AtMostOnceDelivery wsrmp:InOrder='true|false' wsp:Ignorable='true'/>

<wsrmp:AtLeastOnceDelivery wsrmp:InOrder='true|false' wsp:Ignorable='true'/>

This approach would give the client (RMS) the choice as to whether to engage with the service

as it could use the policy intersection mode of 'strict' to ensure that it only interacted with

a service provider that supported RM and offered the DA it required. Alternatively, a client

that didn't care what the DA was at the service provider could use the lax mode of intersection

to omit the assertion from the intersection algorithm.

Considerations:

- only ONE DA could be advertised per service endpoint, as there is nothing in the message

that would indicate which was in play since the protocol operates the same in all cases. There is nothing in WS-Policy that can enforce such a constraint (that an assertion be exclusive of others in any alternatives in the policy statement). We would need to have a constraint like:

A Policy statement MUST NOT contain more than one of the DA assertions in its collective

alternatives. A Policy statement MAY include the same DA assertion in more than one alternative.

- Should probably provide guidance on use of the wsp:Ignorable attribute (e.g. SHOULD be used

unless the service is being deployed with knowledge that all consumers of the service will

both understand that assertion and be willing to include it in the policy intersection)

Thoughts?

Sanjay: if the outline is acceptable, Chris F could produce a more exact proposal.

Marc G: I have sympathy for what Jacques and Chris are proposing. I will post my thoughts to the list before the next call.

Sanjay: are there objections to Jacques general proposal.

Jacques: my main point is that people expect the DAs at least once, and ordered delivery. People expect to do this thru policy assertions. Chris has a proposal which may meet these concerns. It does not affect the protocol directly.

Action: Jacques and Chris F will work toward a proposal to resolve PR 35 and 9 for Jan 4 call.

5 Any other business

Meeting adjourned at 5:35 PM Eastern Time.

ws-rx message

1 Roll Call

2 Agenda Approval

1 Approval of the 12/07 Minutes;

2 AI Review

3 New issues

4 Discussion of PR Issues

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

4.2 b> PR026 Retransmission

4.3 c> PR033 back-channel not defined

4.4 d> PR035 Delivery Assurance

5 Any other business