Preliminary 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 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 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 Kazunori Iwasa
|
Fujitsu
Limited*
|
Leave of
Absence
|
|
Mr. Claus
von Riegen
|
SAP AG*
|
Leave of
Absence
|
|
Mr Bernd Eckenfels
|
Seeburger, AG
|
Applicant
|
Meeting is Quorate.
2
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.
3
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.
4
4 Administrative
Issues
�� a> Volunteers
for sponsoring dial-in facility for future calls
5
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: ---
6
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
6.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.
6.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.
7
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.
8
Issue Discussion: Assign owner and discuss
resolution
8.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.
8.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.
8.3
c> i019 Sequence termination on Fault
http://www.oasis-open.org/committees/download.php/14147/ReliableMessagingIssues.xml#i019
8.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.\
9
Any other business
None:
10 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
|