Prelim Minutes of OASIS WS-RX Teleconference

July 20, 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:

Over 2x of 4x voting members, meeting is quorate

Tom Rutt agreed to take minutes.

2 Agenda Approval

Agenda:

Dial-in thanks to Hitachi

Moderator Name: Bob Freund

Tel: 1-866-705-2554 or

Tel: 1-913-227-1201

(Next Conference Time: 07/20/2006 at 3:45:00 PM)

Participant Passcode: 627479779

IRC/Q Mgmt (thanks to DougD): http://webconf.soaphub.org/conf/room/wsrx

Agenda

1) Roll Call

2) Review and approval of the agenda

3) Approval of the Jul 13th, 2006 meeting minutes

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/19174/MinutesWSRX-071306.html

4) AI Review

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

5) New issues since last conf-call

Watch for Marc’s email

6) Issue Discussion:

=======Note=====================

I would like to try us to knock some of the simpler issues on the head. I hope we can have concrete proposals for as many as possible.

================================

i139 Inappropriate Fault destination

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i139

i147 Extensibility (or not) of the Protocol Elements

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i147

i140 add sub-headings to fault descriptions

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i140

i143 messages have to be received for them to be examined

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i143

i144 RMS MessageNumberRollover behavior unclear

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i144

i145 Implications of Sequence Expiration not specified

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i145

====Note=====================

As regards i122-4, I would like to ensure that we leave at least 30 mins for the discussion - last week we didn't get to either Gil or Doug B's proposals.

If for some reason we cannot resolve these issues on this week's call, I propose we use a STV vote on Kavi immediately following the call.

=============================

i122 security profiles

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i122

i124 security composition policy

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i124

i123 security profile agreement

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i123

i113 Tightening up the state tables

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

8) Any other business

Marc G: 145 and 140 should be moved to end, because there is not an agreed concrete proposal on email..

3 Approval of the 7/13 Minutes;

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/19174/MinutesWSRX-071306.html

Tom R moved to approved 7/13 minutes, Doug D seconded.

§ No objections, minutes of 7/13 approved.

4 AI Review

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

Marc G: - Public review list - Open

Bob F: polling in state tables – Open

Bob and Anish for I140 proposal - Open

5 New issues since last conf-call

None.

6 Issue Discussion:

6.1 i139 Inappropriate Fault destination

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i139

Now proposal 3 in issue list:

http://lists.oasis-open.org/archives/ws-rx/200607/msg00087.html

(a)- Replace: "All other faults in this section relate to the processing of RM header blocks targeted at known Sequences" with:

"All other faults in this section relate to known Sequences"

(b)- Replace: "Entities that generate Sequence faults SHOULD send those faults to the same [destination] as <wsrm:SequenceAcknowledgement> messages"

with:

"RM Destinations that generate Sequence faults SHOULD send those faults to the same [destination] as <wsrm:SequenceAcknowledgement> messages."

Jacques presented his proposal.

Marc G moved to accept proposal to resoluve i139, Doug D seconded.

§ No objections, issue i139 resolved.

6.2 i147 Extensibility (or not) of the Protocol Elements

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i147

Outline of three proposals is here: http://lists.oasis-open.org/archives/ws-rx/200607/msg00059.html

Hi all,

I'd hoped we would have time to discuss this issue on the last call, but

it didn't happen. What I'd like is for the TC to express the direction

that you'd like to take, and then I'll do the legwork to get a concrete

proposal on list before Thursday. Hopefully that will give us at least one

easy issue this week :)

There are currently 3 directions on offer:

1. Add extensibility, so that it is consistently everywhere. This is the

proposal 1 in the original issue

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i147

2. Remove some extensibility, so that only top-level elements allow

extensions. This is proposal 2 in the issue

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i147

3. Do minimal change to get the exemplars, text, and schema in sync (with

that order - e.g. no exemplar change, and force the schema into line

last).

This is my interpretation of what Chris and Marc suggested, but we don't

have concrete text for it yet. Arguably, this is a delta that can be

managed by the editors.

My opinion is that I can go with Chris / Marc's preferred option of

minimal change at this point in the spec lifecycle. Equally, I'd be happy

with 2 (the changes may look scary, but they mostly just remove

extensibility from the wsrm:Identifier element, and I'm not sure when

you'd want to extend that).

If you can let me know how you feel about this one then we should be able

to get some consensus before the call.

Thanks

Matt

I have added the third option in that mail to the issue list as proposal 3.

Additional suggestions from Doug B. for proposal 2. (not sure this is a separate proposal, looks like an amendment)

http://lists.oasis-open.org/archives/ws-rx/200607/msg00079.html

Matt suggested that we take variant 3.

Doug : the reason I liked variant 2) in that it starts with a consistent approach to extensibility.

Gil: I do not quite understand what 3) asks for.

Matt: the prose in the text needs to be reflected in the exemplars and then the schema.

Chris F: Leave work to the editors, to make the text internally self consistent

Doug D: would Doug B be happy if we added extensibility where needed thru separate issues.

Doug B: I can live with 3, but I prefer extensibility in supertypes.

Marc G: I move to adopt variant 3 to resolve i147, seconded by Chris F.

§ No objections, issue I147 resolved with proposed variant 3..

6.3 i143 messages have to be received for them to be examined

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i143

Proposal 1 in the issue list is still all I have seen.

http://lists.oasis-open.org/archives/ws-rx/200606/msg00200.html

Bob presented his proposal.

In WD 15 Section 302 “Closing a Sequence” it states starting on line 428:

“If the RM Source wishes to close the Sequence, then it sends a CloseSequence element, in the body of

a message, to the RM Destination. This message indicates that the RM Destination MUST NOT receive

any new messages for the specified Sequence, other than those already received at the time the

CloseSequence element is interpreted by the RM Destination. Upon receipt of this message, or

subsequent to the RM Destination closing the Sequence of its own volition, the RM Destination MUST

include a final SequenceAcknowledgement (within which the RM Destination MUST include the Final

element) header block on any messages associated with the Sequence destined to the RM Source,

including the CloseSequenceResponse message or on any Sequence fault transmitted to the RM Source.

While the RM Destination MUST NOT receive any new messages for the specified Sequence it MUST still

process RM protocol messages. For example, it MUST respond to AckRequested, TerminateSequence

as well as CloseSequence messages. Note, subsequent CloseSequence messages have no effect on the

state of the Sequence.

In the case where the RM Destination wishes to discontinue use of a Sequence it is RECOMMENDED

that it close the Sequence. Please see Final and the SequenceClosed fault. Whenever possible the

SequenceClosed fault SHOULD be used in place of the SequenceTerminated fault, whenever

possible, to allow the RM Source to still receive Acknowledgements.

”

All messages that reach the RM Destination are received, if they were not then this language would be unnecessary.

I suggest that we use the word “accept” in these cases as in the proposal below in addition to a few editorial nits:

changes are highlighted in yellow and surrounded by “*”

“If the RM Source wishes to close the Sequence, then it sends a CloseSequence element, in the body of

a message, to the RM Destination. This *element* indicates that the RM Destination MUST NOT *accept*

any new messages for the specified Sequence, other than those already *accepted* at the time the

CloseSequence element is interpreted by the RM Destination. Upon receipt of this *element*, or

subsequent to the RM Destination closing the Sequence of its own volition, the RM Destination MUST

include a final SequenceAcknowledgement (within which the RM Destination MUST include the Final

element) header block on any messages associated with the Sequence destined to the RM Source,

including the CloseSequenceResponse *element* or on any Sequence fault transmitted to the RM Source.

While the RM Destination MUST NOT *accept* any new messages for the specified Sequence it MUST still

process *messages containing* RM protocol *elements*. For example, it MUST respond to AckRequested, TerminateSequence as well as CloseSequence *elements*. Note, subsequent CloseSequence *elements* have no effect on the state of the Sequence.

In the case where the RM Destination wishes to discontinue use of a Sequence it is RECOMMENDED

that it close the Sequence. Please see Final and the SequenceClosed fault. Whenever possible the

SequenceClosed fault SHOULD be used in place of the SequenceTerminated fault, whenever

possible, to allow the RM Source to still *process* Acknowledgements.”

Continue with a similar pattern through the remainder of the document

Peter Niblett: The markup proposes other changes that relating to the problem description.

Bob This text could be further refined by introducing new issues to refine. Changing “received” word to “accept” word would help. Other changes to clarify that this is to element not message is a separable new issue.

Peter Niblett: can we agree to remove changes regarding “element” to “message”

Peter: why to we need to change receive to accept. The definition of receive includes qualifying it.

It was agreed to move on, and leave this for further refined proposals.

….

6.4 i144 RMS MessageNumberRollover behavior unclear

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i144

Proposal 1 in the issue list is still all I have seen.

http://lists.oasis-open.org/archives/ws-rx/200606/msg00212.html

Doug D: rather than close with no action, the RMD should be generating. W should

remove all references to RMS solves the problem.

Chris: that is the first chunk of text is kept.

If the message number exceeds the internal limitations of an RM Destination or reaches the

maximum value of 9,223,372,036,854,775,807 the RM Destination MUST Transmit a

MessageNumberRollover fault. The RM Destination should continue to accept, and the RM

Source should continue to retransmit, unacknowledged messages until the Sequence is closed or terminated.

If the message number exceeds the internal limitations of an RM Destination or reaches the

maximum value of 9,223,372,036,854,775,807 the RM Destination MUST Transmit a

MessageNumberRollover fault. The RM Destination should continue to accept, and the RM

Source should continue to retransmit, unacknowledged messages until the Sequence is closed or terminated.

Moved by Chris F to resolve I144 with acceptance of Chris F proposal for first text chunck. seconded by Bob.

§ No opposition I144 resolved.

6.5 i122-4

i122 security profiles

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i122

i124 security composition policy

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i124

i123 security profile agreement

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i123

BEA/MSFT/IBM – now in issue list as proposal 2

http://lists.oasis-open.org/archives/ws-rx/200607/msg00117.html

Oracle/SAP – Prateek send recent email.

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

Sun (Close with no action) – now in issue list as proposal 4

http://lists.oasis-open.org/archives/ws-rx/200607/msg00088.html

Gil presented his amendment, which is in both proposals. This provides a tighter coupling of rm layer to security layer. The sequence is limited to whatever the security layer can provide.

Doug B: in terms of our charter and requirements that both base proposals seem to fulfill, another reason to close with no action is a time and resources concern. We can take this item off of our agenda and save energy we are wasting on it. Tying rm sequence length to security context created for the create sequence can we done identically with a wss security session. The I121 wording states that doing more than that goes beyond what our document is trying to do.

Paul F: we have three concrete proposals.

Doug B moved to close these three issues with no action, seconded by Jeff M.

Gil: I speak against the current motion. We need an interoperable way to secure a sequence. The RSP group will not be able to profile a solution to this problem.

Doug B: the words we added with I121 make it clear enough. A mechanism that the rmd and wss implementation chooses to use is a matter at the destination end of conversation.

Chris F: I speak against the motion. There is not a compromise to the middle. The IBM/Microsoft proposal has had a lot of discussion and compromise. It is only in the last couple of weeks that Oracle has come up with something different. We should try to wrap this up. RSP needs a piece of spec to profile.

Marc G: I agree with Gil and Oracle. Without this there is nothing for RSP to profile.

Prateek: I would like to speak in favor of this proposal, even though it is against our Oracle solution. There have been no publications of layering analysis on the Microsoft proposal. The architectural analysis is not yet complete.

Gil: I do not agree with Doug B that it is in the hands of the RMD. I want to have an understanding that the RMD and RMS have the same view.

Dave O: BEA has been involved in this since the beginning. Close with no action is not the correct thing to do. We have no solutions to deal with this. We originally opposed a tight coupling of RM with WSS, but this new proposal satisfies our concern. We consider this to be a strong, detailed, and multifaceted available solution. What I would like to do is to move toward calling question and ask that we vote on this.

Jacques: I do not buy the statement that this is outside profiling scope of RSP. Every extensibility point is subject to profile. It could be handled as a profiling issue.

Anish: speaking in favor of motion, what we are trying to solve is a narrow use case. The attacker has to be a trusted peer, in that it has to know what the sequence number is, and the message has to contain multiple tokens (explicit association, rather than implicit association). This is a general pattern, in W-SC, but there may be issues around this as the WS-SC TC proceeds. There are two proposals on the table, claiming to have different degrees of coupling. There is no concensus in this TC Regarding the two proposals. Oracle does not like carrying the str in the create sequence message. This general problem should be solved somewhere else. I do not want a rm specific solution to this general concern.

Paul F vote:

17 Yes

18 No

Several Abstain

§ Motion to Close I122-4 with no action failed.

Marc G moved to accept Microsoft/IBM/BEA proposal. Seconded by Chris F.

Doug B: I am concerned about using the same security token in each direction. There is working about “Keys”. Could the be handled as later issues, or can they be explained now.

Paul F: It is preferable to have that be solved by later issues.

Paul F conducted vote:

21 Yes

12 No

several Abstain

§ Motion to resolve I122-4 with Microsoft/IBM/BEA proposal passed.

6.1 i145 Implications of Sequence Expiration not specified

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i145

Proposal 1 in the issue list is still all I have seen.

http://lists.oasis-open.org/archives/ws-rx/200606/msg00216.html

Doug D: presented a counterproposal, that the sequence just goes away..

Bob F: is there a terminate sequence message, or does the sequence just go away.

Doug D: I would like the sequence to terminate and disappear.

Bob F: I would like to avoid changing the section talking about sequence termination. It should clarify that expiry is a silent termination, or otherwise. It could be a bad or good termination.

Stefan: do we agree on what expiry means.

Doug D: do we believe nothing should go on the wire with expired sequence?

Bob F: it is not required what we specify in communication between application and RM, however the protocol should clarify that expiry is a silent termination, different than the other text on termination.

Stefan: I can agree with this.

Ų Action: Doug D to provide text to resolve I145.

7 Any other business

None

ws-rx message

1 Roll Call

2 Agenda Approval

3 Approval of the 7/13 Minutes;

4 AI Review

5 New issues since last conf-call

6 Issue Discussion:

6.1 i139 Inappropriate Fault destination

6.2 i147 Extensibility (or not) of the Protocol Elements

6.3 i143 messages have to be received for them to be examined

6.4 i144 RMS MessageNumberRollover behavior unclear

6.5 i122-4

6.1 i145 Implications of Sequence Expiration not specified

7 Any other business