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
|