Preliminary Minutes of WS-RX TC Weekly Conference Call
Date: Thursday, 21 July 2005
Time: 01:00pm - 02:30pm PT
0
Conventions
Minutes Style Conventions
Motion text
§
Motion Resolution text
Ø
Action item text
Ø
Potential new issue Text:
Tom Rutt agreed to take the minutes.
1
Roll Call
|
First
Name
|
Last Name
|
Role
|
Company
|
|
Alexander
|
Leyfer
|
Voting
Member
|
Actional Corporation*
|
|
Charlton
|
Barreto
|
Voting
Member
|
Adobe
Systems*
|
|
Mark
|
Little
|
Voting
Member
|
Arjuna Technologies*
|
|
Lei
|
Jin
|
Voting
Member
|
BEA
Systems, Inc.*
|
|
Dave
|
Orchard
|
Voting
Member
|
BEA
Systems, Inc.*
|
|
Gilbert
|
Pilz
|
Voting
Member
|
BEA
Systems, Inc.*
|
|
Ian
|
Jones
|
Applicant
|
BTplc
|
|
Andreas
|
Bjarlestam
|
Voting
Member
|
Ericsson*
|
|
Nilo
|
Mitra
|
Voting
Member
|
Ericsson*
|
|
Jacques
|
Durand
|
Voting
Member
|
Fujitsu
Limited*
|
|
Kazunori
|
Iwasa
|
Voting
Member
|
Fujitsu
Limited*
|
|
Tom
|
Rutt
|
Secretary
|
Fujitsu
Limited*
|
|
Robert
|
Freund
|
Voting
Member
|
Hitachi,
Ltd.*
|
|
Eisaku
|
Nishiyama
|
Voting
Member
|
Hitachi,
Ltd.*
|
|
Nobuyuki
|
Yamamoto
|
Voting
Member
|
Hitachi,
Ltd.*
|
|
Doug
|
Davis
|
Voting
Member
|
IBM*
|
|
Christopher
|
Ferris
|
Voting
Member
|
IBM*
|
|
Paul
|
Fremantle
|
TC Chair
|
IBM*
|
|
Daniel
|
Millwood
|
Member
|
IBM*
|
|
Rebecca
|
Bergersen
|
Voting
Member
|
IONA Technologies*
|
|
Toufic
|
Boubez
|
Voting
Member
|
Layer 7
Technologies Inc.*
|
|
Stefan
|
Batres
|
Voting
Member
|
Microsoft
Corporation*
|
|
Paul
|
Cotton
|
Voting
Member
|
Microsoft
Corporation*
|
|
Colleen
|
Evans
|
Voting
Member
|
Microsoft
Corporation*
|
|
Marc
|
Goodner
|
Voting
Member
|
Microsoft
Corporation*
|
|
Christopher
|
Kurt
|
Voting
Member
|
Microsoft
Corporation*
|
|
Jorgen
|
Thelin
|
Voting
Member
|
Microsoft
Corporation*
|
|
Asir
|
Vedamuthu
|
Voting
Member
|
Microsoft
Corporation*
|
|
Chouthri
|
Palanisamy
|
Voting
Member
|
NEC
Corporation*
|
|
Abbie
|
Barbir
|
Voting
Member
|
Nortel
Networks Limited*
|
|
Paul
|
Knight
|
Voting
Member
|
Nortel
Networks Limited*
|
|
Lloyd
|
Burch
|
Voting
Member
|
Novell*
|
|
Steve
|
Carter
|
Voting
Member
|
Novell*
|
|
Martin
|
Chapman
|
Voting
Member
|
Oracle
Corporation*
|
|
Sumit
|
Gupta
|
Voting
Member
|
Oracle
Corporation*
|
|
Anish
|
Karmarkar
|
Voting
Member
|
Oracle
Corporation*
|
|
Ashok
|
Malhotra
|
Voting
Member
|
Oracle
Corporation*
|
|
jeff
|
mischkinsky
|
Voting
Member
|
Oracle
Corporation*
|
|
Greg
|
Pavlik
|
Voting
Member
|
Oracle
Corporation*
|
|
Heidi
|
Buelow
|
Voting
Member
|
Rogue
Wave Software*
|
|
Michael
|
Bechauf
|
Voting
Member
|
SAP AG*
|
|
Sanjay
|
Patil
|
TC Chair
|
SAP AG*
|
|
Steve
|
Winkler
|
Voting
Member
|
SAP AG*
|
|
Umit
|
Yalcinalp
|
Voting
Member
|
SAP AG*
|
|
Blake
|
Dournaee
|
Observer
|
Sarvega
|
|
Pete
|
Wenzel
|
Voting
Member
|
SeeBeyond Technology Corporation*
|
|
Glen
|
Daniels
|
Applicant
|
Sonic
Software
|
|
Doug
|
Bunting
|
Voting
Member
|
Sun
Microsystems*
|
|
Ram
|
Jeyaraman
|
Voting
Member
|
Sun
Microsystems*
|
|
Vadim
|
Furman
|
Voting
Member
|
webMethods, Inc.*
|
Meeting was quorate.
Voting Members: 46 of 64 (71%)
0
Review and approval of the agenda
Agenda:
1) Roll Call
2) Review and approval of the agenda
3) Approval of the Jul 14th meeting minutes
http://www.oasis-open.org/committees/download.php/13652/MinutesWSRX071405-b.htm
4) Administrvia and Announcements
- WS-RX Editors Sub Committee is now active
- New voting members
- Queue Management on conf-calls
- Any other administrative issues
5) TC Ballots
- Results of ballots closed in last week
a> Charter clarification proposal (1 of 2: Bunting)
http://www.oasis-open.org/apps/org/workgroup/ws-rx/ballot.php?id=803
b>Charter clarification proposal (1 of 2: Bunting)
http://www.oasis-open.org/apps/org/workgroup/ws-rx/ballot.php?id=804
- Redmond F2F Attendance ballot open
6) AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
7) New issues since last conf-call
See Marcs email on this topic
8) Issue Discussion: Assign owner and discuss resolution
i011 Typo in expires POS
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13697/ReliableMessagingIssues.xml#i011
i006 Source based delivery QoS policy assertion
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13598/ReliableMessagingIssues.xml#i006
Please see Tom's posting on 7/14 for use cases and motivations:
http://lists.oasis-open.org/archives/ws-rx/200507/msg00108.html
i008 Policy assertions granularity
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13598/ReliableMessagingIssues.xml#i008
i009 Declaration of QoS policies
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13598/ReliableMessagingIssues.xml#i009
9) Any other business
Chris F: we discussed reordering the issues for discussion.
Sanyaj: that should be ok.
lkj
1
Approval of the Jul 14th meeting minutes
http://www.oasis-open.org/committees/download.php/13652/MinutesWSRX071405-b.htm
Tom Incorporated changes posted to the list.
Tom Rutt moved,
Pete Wenzel seconded to approve the 7/14 minutes.
§
No Opposition Minutes approved.
2
Administria and
Announcements
- WS-RX Editors Sub Committee is now active
- New voting members
- Queue Management on conf-calls
IRC channels are the best way to do this.
The chair will post the irc channel information for future calls
- Any other administrative issues
3
TC Ballots
- Results of ballots closed in last week
3.1
Charter clarification proposal (1 of 2: Bunting)
http://www.oasis-open.org/apps/org/workgroup/ws-rx/ballot.php?id=803
79%, 2 no. This ballot succeeded.
3.2
Charter clarification proposal (2 of 2: Mischkinsy))
http://www.oasis-open.org/apps/org/workgroup/ws-rx/ballot.php?id=804
38% no votes, ballot fails.
3.3
Redmond
F2F Attendance ballot open
Sanjay asked members to post their answers to this ballot soon.
Paul C: if people who will not attend would register that using the ballot , it will help. I need to know soon if there will be more than 50 people.
4
AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
#0002: OASIS Staff should fix typographical error in charter of missing space between “produces” and “to” the next time the charter is updated.
Owner: James Bryce Clark
Status: Open – Jamie will do this by next week.
Assigned: 2005-07-06
Due: 2005-07-08
#0007: Sanjay to set up editing team Subcommittee or mailing list
Owner: Sanjay Patil
Status: Closed
Assigned: 2005-07-08
Due: 2005-07-14
#0011: Chairs should start a KAVI ballot asking members if they will attend the Face to Face meeting, either in person or by teleconference
Owner: Paul Fremantle
Status: Closed
Assigned: 2005-07-17
Due: ---
#0012: Chair took an action item to get a ruling from Jamie on CVS repository usage.
Owner: Paul Fremantle
Status: Open – There are remaining discussion required
Assigned: 2005-07-17
Due: ---
#0013: Chairs will propose a mechanism to manage the Queue on the conference calls.
Owner: Sanjay Patil
Status: Open – desire to use IRC channel, need permanent solution
Assigned: 2005-07-17
Due: ---
5
New issues since last conf-call
From Marcs email on this topic
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00193.html
|
proposed-01
|
Is an implementation supporting a
smaller max message number valid?
|
core -
design - unassigned
|
|
|
Description
The existing
specification includes the clause "If the message number exceeds the
internal limitations of an RM Source or RM Destination ...".
This allows a source or destination to handle unexpected failures gracefully.
It does not clearly allow, require, or prevent the implementation to be
designed or deployed with a message number limit. Should we support such a
limitation? Related to i013.
Justification
Issue below
presupposes a "yes" answer to this question. Should decide this
larger question before deciding how to fill gap left if the answer is
"yes".
Origin
Doug
Bunting
Proposal 12005-07-14
I lean toward
"no" but could be convinced otherwise. If "no" is the
answer, the specification could change to make it clear a WS-RM compliant
implementation _must_ support the full unsigned long range for the message
number. That likely requires conformance terminology not presently in the
specification; this issue is not intended to broach the even-more-general
subject of conformance clauses. My proposal therefore comes down to
"close, no action".
|
|
proposed-02
|
Sequence termination on Fault
|
core -
design - unassigned
|
|
|
Description
The RM
Destination imperatively terminates a sequence due to one of these
unrecoverable errors:
- wsrm:SequenceTerminated
- wsrm:MessageNumberRollover
- wsrm:LastMessageNumberExceeded
The semantics
of sequence termination due to a fault occurrence are not clearly specified.
This uses the reworded
issue
Justification
Unless an
accurate and final acknowledgement status was sent back at the time the
sequence is closed, the Source will not know if some non-acknowledged
messages were actually received before the termination occurs. This gives the
source two unpleasant options: (a) resend all non-acknowledged message in a
new sequence, with the risk of causing undetectable duplicates, (b) not
resend any, and these will be lost.
Origin
Jacques
Durand
Proposal 12005-07-15
Two options
need be discussed: Option (1): At the time a Destination-controlled
termination gets into effect, a final and accurate Acknowledgement for the
entire sequence is sent back. Option (2): After the fault was notified to
Source, simply rely on regular termination procedure (either
expiration-based, or under Source control, so that the Source can complete
its resending of pending messages and get the final acks),
meanwhile reject any message for this sequence that exceeds the ending number
in case of MessageNumberRollover or LastMessageNumberExceeded.
|
The first proposed issue was
accepted.
The second proposed issue was
accepted.
Sanjay:
Jacques suggested a new status for issues.
Ø
Action: Marc G should review Jacques suggestion
for new issue status, and report to TC by next week call.
6
Issue Discussion: Assign owner and discuss
resolution
6.1
i011 Typo in expires
POS
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13697/ReliableMessagingIssues.xml#i011
Doug Davis volunteered to take ownership of Issue.
Jeff M moved to accept proposed solution to i011, Chris F
seconded.
§
No objections to Doug’s proposed resolution to
I011, status changed to editor pending.
6.2
i008 Policy assertions
granularity
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13598/ReliableMessagingIssues.xml#i008
Owner Tom Rutt
Tom Rutt: Requirement to have flexibility to attaché policy to the level of operation.
Chris F: the WS-rm policy assertions are currently attached to port type, binding, or port. The spec disallows attaching to port type. Currently attaché only to service:port, or binding.
Ashok: what if policies attachéd at port and binding disagree is there a conflict resolution.
Paul F: in EJB you can attach policy at method level. However, this adds complexity.
Anish: I think there is a dependency on issue 9. If issue 9 states we want to reflect qos assertion in policy, I can see some wanting to attaché those policies at a finer level than port type.
Chris F: this issue deals with the policies which have already been defined.
Sanjay: Is there a requirement with today’s policies
Tom: I think this depends on whether we have the Delivery assurances as Policy assertions.
Sanjay: I propose we defer further discussion on i008 until after discussing i009.
6.3
i009 Declaration of QoS policies
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13598/ReliableMessagingIssues.xml#i009
Chris F: Senders want the ability to know which level of DA Qos may be expected of a destination endpoint.
Chris F; we can define policy assertion indicating what observed DA qos is at an endpoint. Currently there is no way to denote that a policy is observed, in WS-Policy. If we carried it as a parameter of the rm assertion itself we could resolve this.
Umit: are you suggesting an added attribute.
Chris F: the wsrm assertion carries child elements for exponential backoff etc. Those are the parameters. We could add one or two parameters to convey the Delivery assurance.
Joe: Would you put multiple policies in wsdl file and attach to different ports.
Chris F: You could have multiple ports.
Jacques: Knowing which policy is enabled on endpoint is not just a matter of source to choose to use endpoint. If at least once is supported, the source must hold messages until acked. If not supported they do not want to waste time doing retransmission. There is a requirement for the source to be aware of which delivery assurance is in used.
Sanjay: First we should focus on whether this requirement is agreed, before focusing on solutions.
Steve W: Is Jacques stating that the source knowing what DA the destination will apply to the client will change its behaviour.
Jacques; the sender must retransmit only if guaranteed delivery is required.
Paul C: People seem to be implying that if there was a policy statement, that the port supports it. What are people suggesting the policy means. Is this a guarantee for a port that it will always apply. I thought this was between the two aspects of destination. I am not ready to decide on this until I have a better understanding of the requirement. I want to know what the impacts are on the source of knowing this information.
Gil: On chris’s proposal on putting in the policy assertion. With respect to Paul’s comment, the only delivery assurance for which the source must change its behaviour is the at most once. Different delvery assurances have different run time impact. The source might not want to “pay” for ordered delivery if it is not required.
Anish: At most once, alters the behavior of the sender.
Chris F: To clarify Paul C question, we are defining an assertion that a DA is observed at the receiving endpoint. The protocol is an at least once protocol on the wire. From the sending endpoint it might not send if it runs out of space, but that does not affect what goes on the wire. This policy assurance is targetd between RM-Destination and Application Destination.
Paul C: is it a guarantee.
Chris F: yes.
Paul C: you are asserting there is no impact.
Tom Rutt : at most once is the special case.
Chris F: I do not agree that this impacts the sender behaviour.
Tom Rutt; We need to better understand the semantics of at most once.
Doug Davis: At most once affects the client, because it must process the ack.
Jacques: we need to clarify some things here. The ws-policy assertions currently deal with resend policy. The text implies that these policies apply to inbound and outbound messages from an endpoint. This might impact behavour of source to receive these outbound messages.
Chris F: I did not mean to apply the assertions we have to not affect the source. The delivery assertion does not affect what goes on wire.
Sanjay: what does it mean for a destination to apply a DA, and does it affect the source and destination.
Tom R: we need to understand the obligations of source and destination associated with each of the delivery assurances. This will aid our discussion. My contribution on Delivery Assertion Substitutability proposes an initial set of obligations.
Sanjay: We need to determine if the concern is whether the Source needs to know the DA offered by the destination, only to determine if it is good enough for its requirements. If the DA does not impact the required behaviour of source then it simplifies the problem.
Chris F: We are not quite there in understanding this issue. A specific proposal with use cases will help. I would be glad to take that on.
Jeff M: has the TC agreed yet on requirements.
Sanjay: The TC has no clear agreed requirement yet.
Tom: I would ask Chris F to explain his understanding of At Most once, which would require the sender to retransmit. Once I understand this, I can revise my contribution.
Tom: I would like to defer issue discussion on issue 8 before issue 9.
Sanjay: I assign this issue ownership to Chris F.
Jacques: can we adopt a practice that each email title be prefixed with issue number.
Sanjay: put issue number on subject line.
Steve W: follow Marc G guidelines on how to do this in his email.
Jeff M: there is a question about the meaning of at most once. Perhaps a new issue should be raised on that.
Tom R: I agree I will add this as a new issue. What is meaning of at most once.
Umit: I suggest we take every delivery assurance to write a use case where the source needs to be aware of the DA in use.
Sanjip: I believe Chris’s proposal should address that.
6.4
i006 Source based
delivery QoS policy assertion
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13598/ReliableMessagingIssues.xml#i006
Please see Tom's posting on 7/14 for use cases and motivations:
http://lists.oasis-open.org/archives/ws-rx/200507/msg00108.html
Tom Rutt posted a contribution on Substitutability of DA levels, which is relevant to this discussion, at: http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13705/DASubstitution.htm
Defer this to future meeting.
7
Any other business
None
Sanjip: I encourage the TC before F2F each member should submit all their issues on the spec.
Meeting adjourned at normal closing time.