[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: text version of minutes with line breaks
Here are the minutes in text form: 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* Christophe r 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* Christophe r 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 mischkinsk y 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%) 2 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/MinutesWSRX07 1405-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#i0 11 i006 Source based delivery QoS policy assertion http://www.oasis-open.org/apps/org/workgroup/ws- rx/download.php/13598/ReliableMessagingIssues.xml#i0 06 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#i0 08 i009 Declaration of QoS policies http://www.oasis-open.org/apps/org/workgroup/ws- rx/download.php/13598/ReliableMessagingIssues.xml#i0 09 9) Any other business Chris F: we discussed reordering the issues for discussion. Sanyaj: that should be ok. 3 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. 4 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 5 TC Ballots - Results of ballots closed in last week 5.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. 5.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. 5.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. 6 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: --- 7 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. 8 Issue Discussion: Assign owner and discuss resolution 8.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. 8.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. 8.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. 8.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. 9 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. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]