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:

 

Name

Company

Status

Lei Jin

BEA Systems, Inc.*

Group Member

Dave Orchard

BEA Systems, Inc.*

Group Member

Gilbert Pilz

BEA Systems, Inc.*

Group Member

Ian Jones

BTplc*

Group Member

Hamid Ben Malek

Fujitsu Limited*

Group Member

Jacques Durand

Fujitsu Limited*

Group Member

Kazunori Iwasa

Fujitsu Limited*

Group Member

Tom Rutt

Fujitsu Limited*

Group Member

Robert Freund

Hitachi, Ltd.*

Group Member

Nobuyuki Yamamoto

Hitachi, Ltd.*

Group Member

Doug Davis

IBM*

Group Member

Christopher Ferris

IBM*

Group Member

Matt Lovett

IBM*

Group Member

Anthony Nadalin

IBM*

Group Member

Peter Niblett

IBM*

Group Member

Mark Little

JBoss Inc.*

Group Member

Stefan Batres

Microsoft Corporation*

Group Member

Paul Cotton

Microsoft Corporation*

Group Member

Colleen Evans

Microsoft Corporation*

Group Member

Marc Goodner

Microsoft Corporation*

Group Member

Ondrej Hrebicek

Microsoft Corporation*

Group Member

Asir Vedamuthu

Microsoft Corporation*

Group Member

Paul Knight

Nortel Networks Limited*

Group Member

Lloyd Burch

Novell*

Group Member

Steve Carter

Novell*

Group Member

Martin Chapman

Oracle Corporation*

Group Member

Anish Karmarkar

Oracle Corporation*

Group Member

Ashok Malhotra

Oracle Corporation*

Group Member

jeff mischkinsky

Oracle Corporation*

Group Member

Prateek Mishra

Oracle Corporation*

Group Member

Eric Rajkovic

Oracle Corporation*

Group Member

David Burdett

SAP AG*

Group Member

Sanjay Patil

SAP AG*

Group Member

Martin Raepple

SAP AG*

Group Member

Stefan Rossmanith

SAP AG*

Group Member

Mark Schenecker

SAP AG*

Group Member

Steve Winkler

SAP AG*

Group Member

Umit Yalcinalp

SAP AG*

Group Member

Doug Bunting

Sun Microsystems*

Group Member

Mike Grogan

Sun Microsystems*

Group Member

Pete Wenzel

Sun Microsystems*

Group Member

Dan Leshchiner

Tibco Software Inc.*

Group Member

Shivajee Samdarshi

Tibco Software Inc.*

Group Member

Lily Liu

webMethods, Inc.*

Group Member

Paul Fremantle

WSO2*

Group Member

 

 

38 of 41 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 exemplars should be taken as correct, and be reflected by the  prose in the spec 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.1      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.2      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.3      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

_______________________________________________________________________
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.