Minutes of WS-RX TC Weekly Conference Call

Date:  Thursday, 01 September 2005

Time:  01:00pm - 02:30pm PT

1         Roll Call

<From Kavi>

Member

Company

Member Type

Alexander Leyfer

Actional Corporation*

Voting Member

Dr. Charlton Barreto

Adobe Systems*

Voting Member

Dr Mark Little

Arjuna Technologies Limited*

Voting Member

Mr. Lei Jin

BEA Systems, Inc.*

Voting Member

Dave Orchard

BEA Systems, Inc.*

Voting Member

Gilbert Pilz

BEA Systems, Inc.*

Voting Member

Mr Ian Jones

BTplc*

Voting Member

Andreas Bjarlestam

Ericsson*

Voting Member

Mr Jacques Durand

Fujitsu Limited*

Voting Member

Mr Kazunori Iwasa

Fujitsu Limited*

Voting Member

Mr Robert Freund

Hitachi, Ltd.*

Voting Member

Mr Eisaku Nishiyama

Hitachi, Ltd.*

Voting Member

Mr Nobuyuki Yamamoto

Hitachi, Ltd.*

Voting Member

Mr. Doug Davis

IBM*

Voting Member

Mr Christopher Ferris

IBM*

Voting Member

Mr. Daniel Millwood

IBM*

Voting Member

Mr Peter Niblett

IBM*

Voting Member

Ms. Rebecca Bergersen

IONA Technologies*

Voting Member

Mr. Stefan Batres

Microsoft Corporation*

Voting Member

Mr. Paul Cotton

Microsoft Corporation*

Voting Member

Ms Colleen Evans

Microsoft Corporation*

Voting Member

Mr Marc Goodner

Microsoft Corporation*

Voting Member

Mr. Jonathan Marsh

Microsoft Corporation*

Voting Member

Mr. Jorgen Thelin

Microsoft Corporation*

Voting Member

Asir Vedamuthu

Microsoft Corporation*

Voting Member

Mr. Chouthri Palanisamy

NEC Corporation*

Voting Member

Dr Abbie Barbir

Nortel Networks Limited*

Voting Member

Mr Paul Knight

Nortel Networks Limited*

Voting Member

Mr Lloyd Burch

Novell*

Voting Member

Dr Martin Chapman

Oracle Corporation*

Voting Member

Mr Sumit Gupta

Oracle Corporation*

Voting Member

Dr. Anish Karmarkar

Oracle Corporation*

Voting Member

Mr Ashok Malhotra

Oracle Corporation*

Voting Member

jeff mischkinsky

Oracle Corporation*

Voting Member

Mr Greg Pavlik

Oracle Corporation*

Voting Member

Mr Eric Rajkovic

Oracle Corporation*

Voting Member

Mr. Claus von Riegen

SAP AG*

Voting Member

Mr Steve Winkler

SAP AG*

Voting Member

Dr Umit Yalcinalp

SAP AG*

Voting Member

Pete Wenzel

SeeBeyond

Voting Member

Vikas Deolaliker

Sonoa Systems, Inc.*

Voting Member

Doug Bunting

Sun Microsystems*

Voting Member

Mr. Dan Leshchiner

Tibco Software Inc.*

Voting Member

Mr. Shivajee Samdarshi

Tibco Software Inc.*

Voting Member

Mr Sanjay Patil

SAP AG*

TC Chair

Mr. Paul Fremantle

WSO2*

TC Chair

Mr Tom Rutt

Fujitsu Limited*

Secretary

Rich Salz

Datapower Technology, Inc*

Member

Dr. Toufic Boubez

Layer 7 Technologies Inc.*

Member

Mr Bernd Eckenfels

Seeburger, AG

Applicant

 

 

Meeting is Quorate.

1         Review and approval of the agenda

Agenda:

1) Roll Call

 

2) Review and approval of the agenda

 

3) Approval of the Sep 1st 2005 meeting minutes

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

 

4) Administrative Issues

a> Volunteers for sponsoring dial-in facility for future calls

 

5) AI Review

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

 

6) New issues since last conf-call

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

 

7) Use cases

We will decide on whether the use cases are to be (1) accepted (2) in-scope.

Discussion will be limited to 5mins per UC. If the discussion is not complete, the decision will be postponed until further consensus is

built on the mailing list.

 

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

Broker Interface

 

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

Commodity Quotes Service

 

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

Smartphone Subscribes to Service

 

8) Issue Discussion: Assign owner and discuss resolution

 

a> i012 Anonymous acksTo

http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i012

 

b> i005 Source resend of nacks messages when ack already received

http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i005

 

c> i019 Sequence termination on Fault

http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i019

 

d> i028 Accurate final acknowledgement of a Sequence with gaps when RMS decides to stop using it

http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i028

 

9) Any other business

 

Marc G suggested we postpone the discussion of the use cases.

 

Paul F: is it well formed is one question,  is it in or out of scope of the spec is another question.  It seams that the second aspect is more important than the first aspect. 

 

Marc G: The use case motion did not refer to charter scope, it is the discussion of versions which I am not ready to discuss.

 

Gil: I suggest that we change the agenda to just have them added to the document, leaving all scope discussions to occur down the road.  A given use case may, after discussion, make the realization that it is too much for the next protocol versions.

 

Paul F: Can we agree to change use case agenda item for this meeting to not include version scope in the decision to accept a use case.

 

Anish: The TC can decide a use case is out of scope.   I am not sure why this is more difficult than the normal issues list.

 

Dave O: the issue of scoping can be left out of the text in the use case.  Version scoping can be left to later.

 

Paul F: are there any objections to this charter change?

 

Anish: Is there an assumption that we would make a scope resolution at some later point in time?

 

M Chapman: what is our obligation with respect to use cases.

 

Paul F: they are there to help the committee resolve their issues.

 

Marc G: I want to make it clear that the resolution of an issue is where scope determination is done for normal issues.

 

No objection to agenda change for use cases.

 

Marc G asked that we limit debate, to allow time to get thru all issues.

2         3 Approval of the Sep 01, 2005 meeting minutes

   http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14309/Minutes-wsrx-090105.htm

 

Rebeccat moved to approve the Sep 01 , minutes, Tom R seconded.

 

No opposition, minutes approved.

3         4 Administrative Issues

   a> Volunteers for sponsoring dial-in facility for future calls

 

 

4         5 AI Review

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

 

Report created 08 September 2005 02:56pm EDT

 

#0002: OASIS Staff should fix typographical error in charter of missing space between “produces” and “do” the next time the charter is updated.

Owner: James Bryce Clark

Status: Open – Still Open, they have not posted any charter changes.

Assigned: 2005-07-06

Due: 2005-07-08

 

#0012: Chair took an action item to get a ruling from Jamie on CVS repository usage.

Owner: Paul Fremantle

Status: Open – wait for OASIS proposal , Paul will talk to Jamie on this since the editors need it.

Assigned: 2005-07-17

Due: ---

 

#0024: Provide concrete proposal for issue "InOrder delivery assurance spanning multiple sequences"

Owner: Andreas Bjarlestam

Status: Closed, proposal was posted.

Assigned: 2005-08-12

Due: 2005-08-25

 

#0025: Propose a "namespace change policy" for the schemas produced by the TC

Owner: Christopher Ferris

Status: Open

Assigned: 2005-08-23

Due: ---

 

#0026: Propose new resolution to I005, reflecting TC discussion

Owner: Steve Winkler

Status: Closed, Steve posted proposal.

Assigned: 2005-08-29

Due: ---

 

#0028: Create Implementation SC

Owner: Sanjay Patil

Status: Closed – any member can join the SC

Assigned: 2005-09-05

Due: 2005-09-08

 

#0029: Editors to propose a resolution to proposed 02 for voting at the next meeting

Owner: Anish Karmarkar

Status: Open -

Assigned: 2005-09-06

Due: ---

 

5         New issues since last conf-call

 

-  New proposed issues 9/1 - 9/7
From "Marc Goodner" <mgoodner@microsoft.com> on 7 Sep 2005 23:05:50 -0000

 

5.1      proposed-01

Title: Processing model of NACKs

 

Description: Although it is assumed that a NACK will trigger

retransmission of a given message from the source to the destination

there is no wording in the current version of the spec that describes

this feature adequately.

 

Justification: This will clarify to implementers the spirit of the spec

by spelling out in more concrete terms what is currently only implied.

 

Origin: Steve Winkler [steve.winkler@sap.com]

Target: Core

Type: Design

 

Proposal:

Add the following to the spec directly before the text that is

incorporated as a resolution to i005:

Upon the receipt of a Nack, an RM Source SHOULD retransmit the message

identified by the Nack as soon as possible.

 

Paul F: Is there any objection to adding this issue.

 

No objection: issue agreed to be added as new issue.

5.2      proposed-02

Title: If a fault is generated whilst processing a piggy-backed

AckRequested or SequenceAcknowledgement header, should this stop

processing of the entire message?

 

Description: In Section 3.2 of the spec, it states that 'The

<SequenceAcknowledgment> header block MAY be transmitted independently,

or included on return messages'.  A similar statement is made in Section

3.3, 'The RM Source endpoint requests this Acknowledgment by including

an <AckRequested> header block in the message'.  In both cases, the

header can be piggy-backed on a message going to the relevant endpoint.

 

If during the processing of this header, a fault occurs, the spec does

not state what should happen.  Consider the case where an AckRequested

is piggy-backed on a non WS-RM message that happens to be going to the

correct endpoint.  If the AckRequested turns out to be for an

UnknownSequence, the spec states that the fault processing should be as

per WS-Addressing, however any EPRs defined in the message are

potentially application EPRs and not WS-RM EPRs, so sending a fault to

the applications FaultTo EPR may not be the correct thing to do.

 

Justification: The piggy-backing of headers is an optimization and as

such, it is questionable whether their processing should affect the

processing of the original message.  The spec should be clear on the

expected behaviour of the RM Source and the RM Destination in these

cases.

 

Origin: Daniel Millwood [MILLWOOD@uk.ibm.com]

Target: core

Type: design

 

Proposal:  Change the wording of the spec to be along the lines of "If a

fault occurs when processing an RM Header that was piggy-backed on

another message, a fault MUST be generated, but the processing of the

original message MUST NOT be affected.

 

Tom R: accepting the issue does not mean accepting the proposal?

 

Paul F: correct.

 

No opposition to adding the issue.

6         Use Case Issues

 

We will decide on whether the use cases are to be (1) accepted (2) in-scope.

Discussion will be limited to 5mins per UC. If the discussion is not complete, the decision will be postponed until further consensus is

built on the mailing list.

 

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

Broker Interface

 

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

Commodity Quotes Service

 

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

Smartphone Subscribes to Service

 

Gil moved to add all three use cases to the use case doc, Tom R seconded.

 

No objection, the three use cases will be added to the use case document.

7         Issue Discussion: Assign owner and discuss resolution

 

7.1      a> i012 Anonymous acksTo

http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i012

 

Lei: there is a ackTo.  There are cases in which can take on the value AnonymousURI, which entails use of the http back channe.  There are cases when this is not appropriate, (one way).  Anish stated in an email that this pattern could be useful.

 

 

Lei: I would like to disallow this in these troublesome cases.

 

Chris F: I to not think this is an issue, we must allow anonymous for ackTo.  There are many use cases where anonymous is the only way to get ack back.  I am fundamentally opposed to removing it.

 

Anish: What is the final proposal: disallow anonymous in oneway case, and send protocol ack.

 

Lei: Yes.

 

Dave O: we have to look at the world out there, including the WS-I profiles.  We cannot ignore the profile, in cases where there are problems with something which may be widely adopted, we have to deal with it.

 

Tom R: I do not see why we have to describe in detail cases where something cannot work.  Perhaps a Note could be added to the spec regarding ws-I bp compliant usage of anonymous with one-way wsdl operations.

 

Dave O: We need to state how we compose with other specs.

 

Anish: Lei proposal is to put in words about wsdl one way MEP with ws-I BP 1.1.  In this case the transport or binding does not allow a back channel for anonymous.  Since it is not available I do not see what clarification this would add.

 

Lei: If there is no back channel do not use it seems to be the consensus.  I would like to clarify what is to happen when it occurs.

 

Anish: If there is no back channel you cannot use anonymous.

 

Lei: we want to make sure that when one way is being used there is no back channel.  This is not obvious to everyone.  I would also like people to know how to do acks when there is no back channel.

 

Chris F: the RM source will only send ackTo addresses which it can deal with.  It seems we would be cutting ourselves off for future extensions if we make statements in this area.  Why say anything about using ack requrested with anonymous URL.

 

Gil: People say it is obvious that a one way should not use anonymous ackTo.  If different people are writing different layers it is not always obvious.

 

Paul F: would this not be a deployment concern for that application.

 

Gill: there could be one to may rms to application mappings.

 

Paul F: it is up to the application deployer to use appropriate ackTo values.

 

Lei: On the destination side, if intermediary forwards to rmd, it could close connecton if it is one way.  The rmd cannot return it in that case.

 

Chris F: The profile says if you send over http receiver sends back 202.  It does not count intermediary as receiver.  I do not see the intermediary concern expressed by Lei.

 

Doug B: If an RMS is fully configured in such a broken manner, the worst that can happen is initial test message fails, and the admin determines the probem, then fixes it.  What am I missing?

 

Dave O: Chris F’s Store and forward intermediary example behaviour assumptions need to be clarified.

 

Chris F: I think it is a premature optimization to have an intermediary work in the manner described by Lei.  If it will not work the sender will not use anonymousURI in ackTo.

 

Dave O: Is there a middle ground to describe cases where anonymousURI cannot work.

 

Chris F: I do not think this needs to be stated in the spec, since it is a matter of configuration.  Soap 1.1 has no mention of store and forward.

 

Anish: There is another point to resolve. Currently anonymousURI when used in acksTo is undefined.  WS addressing only specifies the use in their header elements.  I had sent a mail out on this.

 

Paul F: can you raise this as a new issue.

 

Anish: I can raise that as a new issue.

 

Doug D: I think our spec can be silent on use of anonymousURL.

 

The discussion ensued on the need to fix a problem in this issue.

 

Lei: The store and forward case example if any one way with intermediary.  This could have problems with anonymous ack to.

 

Umit: This issue only applies when intermediaries are in scope.  We have been arguing whether receiver role for wsrm applies to intermediaries.  Since this is uncharted ground, we should be silent in our spec on this.

 

Tom Rutt moved to close issue 12 without change to spec and Chris F seconded.

 

No further discussion.

 

Paul: are there any objections to the motion.

 

Lei has objection,

 

Roll Call Vote  see rollCallVoteOnIssue012Resolution:

 

.  29 for, 4 against, 8 abstain.  Motion carries.

 

7.2      b> i005 Source resend of nacks messages when ack already received

http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i005
 
Steve W send out a proposal, after review of discussion.
  • Issue i005
    From "Winkler, Steve" <steve.winkler@sap.com> on 6 Sep 2005 18:55:27 -0000

 

Steve moved to close issue i005 by adding following text to the spec:

An RMD MUST NOT issue a <SequenceAcknowledgement> containing a <Nack> for a message(s) that it has previously acknowledged within an <AcknowledgementRange>.

An RMS SHOULD ignore a <SequenceAcknowledgement> containing a <Nack> for a message(s) that has previously been acknowledged within an <AcknowledgementRange>.

Tom Rutt Seconded the motion.
 
No objection, close issue 005 with Steve’s proposal.
 

7.3      c> i019 Sequence termination on Fault

http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i019
 

7.4      d> i028 Accurate final acknowledgement of a Sequence with gaps when RMS decides to stop using it

http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i028
 
 
Doug D send proposal as:

Umit moved to accept Doug’s proposal, Tom Rutt seconded.

 

Discussion:

 

Jorgen asked what changes from Rebecca’s email are included.

 

Contents of Rebecca email:

 

You say, “After line 396, add a new section ….”  I believe you mean line 596.

 

You say “The following exemplar defines the CloseSequence syntax:  Exemplars don’t define.  How about “The following defines the CloseSequence syntax:  ?

 

 

 

Doug D: fixing the one line number as suggested by Rebecca, is the only change I believe is required to close this issue. The second change affects other parts of the text in the spec.

 

Anish: Does the proposal allow the editors leeway in non normative aspects.

 

Rebecca: what is the concern about the second change?

 

Doug D: I objected to the second question by Rebecca only that it is a different editorial issue, since that text is used in many places.  This could be raised as a separate issue.

 

Marc G: I have concerns about this proposal.  It is making a change to the semantics of termination of sequence.  It has problems, in that it opens up holes, which give ways to not have the sequence terminated.  It requires the rms to know the delivery assurance required on the RMD side.  I am concerned that this proposal has been continuously modified.

 

Paul F: we need to have proper debate on the technical concerns, rather than editorial matters.

 

Doug D: This proposal does not change termination causes, and I do not see how it makes the rms require knowing the da in use by the RMD.

 

Anish: I do not understand how this proposal makes the rms know what is used by RMD.

 

Jacques: the proposal does not change the semantics of closure, it just provides a marker for what is already a termination case.  As for the DA semantics, I do not see any requirement for the RMS to be aware of the DA.  The protocol should use this signal regardless.

 

Discussion Terminated for lack of Time,  Continue discussion of this issue on mailing list and call.

 

Chris F: can this be higher on agenda next week.

 

Paul F: we can put this first on the agenda for next week.\

 

8         Any other business

None:

 

 

9         Roll Call Vote for Motion on Issue 012

 

First Name

Last Name

Role

Company

Issue 12 motion

Kazunori

Iwasa

Leave of Absence

Fujitsu Limited*

y

Tom

Rutt

Secretary

Fujitsu Limited*

y

Alexander

Leyfer

Voting Member

Actional Corporation*

y

Charlton

Barreto

Voting Member

Adobe Systems*

y

Jacques

Durand

Voting Member

Fujitsu Limited*

y

Peter

Niblett

Voting Member

IBM*

y

Doug

Davis

Voting Member

IBM*

y

Christopher

Ferris

Voting Member

IBM*

y

Daniel

Millwood

Voting Member

IBM*

y

Rebecca

Bergersen

Voting Member

IONA Technologies*

y

Jorgen

Thelin

Voting Member

Microsoft Corporation*

y

Colleen

Evans

Voting Member

Microsoft Corporation*

y

Marc

Goodner

Voting Member

Microsoft Corporation*

y

Stefan

Batres

Voting Member

Microsoft Corporation*

y

Jonathan

Marsh

Voting Member

Microsoft Corporation*

y

Asir

Vedamuthu

Voting Member

Microsoft Corporation*

y

Chouthri

Palanisamy

Voting Member

NEC Corporation*

y

Paul

Knight

Voting Member

Nortel Networks Limited*

y

Abbie

Barbir

Voting Member

Nortel Networks Limited*

y

Ashok

Malhotra

Voting Member

Oracle Corporation*

y

Sumit

Gupta

Voting Member

Oracle Corporation*

y

Eric

Rajkovic

Voting Member

Oracle Corporation*

y

Anish

Karmarkar

Voting Member

Oracle Corporation*

y

jeff

mischkinsky

Voting Member

Oracle Corporation*

y

Martin

Chapman

Voting Member

Oracle Corporation*

y

Pete

Wenzel

Voting Member

SeeBeyond *

y

Doug

Bunting

Voting Member

Sun Microsystems*

y

Shivajee

Samdarshi

Voting Member

Tibco Software Inc.*

y

Dan

Leshchiner

Voting Member

Tibco Software Inc.*

y

Gilbert

Pilz

Voting Member

BEA Systems, Inc.*

n

Lei

Jin

Voting Member

BEA Systems, Inc.*

n

Dave

Orchard

Voting Member

BEA Systems, Inc.*

n

Vikas

Deolaliker

Voting Member

Sonoa Systems, Inc.*

n

Sanjay

Patil

TC Chair

SAP AG*

a

Paul

Fremantle

TC Chair

WSO2*

a

Ian

Jones

Voting Member

BTplc*

a

Andreas

Bjarlestam

Voting Member

Ericsson*

a

Nobuyuki

Yamamoto

Voting Member

Hitachi, Ltd.*

a

Robert

Freund

Voting Member

Hitachi, Ltd.*

a

Steve

Winkler

Voting Member

SAP AG*

a

Umit

Yalcinalp

Voting Member

SAP AG*

a