[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim Minutes of 10/06 Teleconf
Prelim Minutes are attached. Please post corrections to the list before Monday Morning. Tom Rutt WSRX TC Secretary -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Preliminary Minutes WSRX TC Teleconf
|
Preliminary Minutes WSRX TC Teleconf October 06, 2005 – 1 Roll Call<from Kavi>
Voting Members: 8 of 55 (Quorate) 2 Review and approve of Agenda1) Roll Call 2) Review and approval of the agenda 3) Approval of the F2F meeting minutes 4) Administrative Issues 5) AI Review 6) Committee Draft status from editor team including open questions (e.g. yyyy/mm) 7) New issues since last conf-call 8) Issue Discussion: Issue 30: What are the obligations on RMD for use (or not) of Offered Sequence? Issue 48: CloseSequenceResponse and Acks Issue 24: WS-RX policies not manifested on the wire Issue 21: An RM Policy applies two-way Issue 8: Policy assertions granularity Issue 6: Source based delivery QoS policy assertion 9) Any other business Tom R: asked to Reorder 21 before 008. No disagreement 1 Approval of Face To Face meeting minutesApproval of F2F meeting minutes http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14693/MinutesWSRXF2f-0905.htm Tom Rutt moved, Becky seconded to approve the face to face minutes § No objection, Face To Face Minutes Approved. 2 Administrative IssuesPaul stated that this number, which is not toll free, will be used for a while. 3 AI Review#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: closed 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 – Doug Davis is waiting information from OASIS Staff. Jeff M stated they have a CVS but are figuring out how to administrer it. Assigned: 2005-07-17 Due: --- #0031: Open two issues around cancel / fill proposal and use cases Owner: Stefan Batres Status: Open Assigned: 2005-09-21 Due: 2005-09-29 #0032: Create a proposal for i024 Owner: Ashok Malhotra Status: closed Assigned: 2005-09-21 Due: 2005-09-29 #0033: Anish will propose text to clarify in the current document the protocol is at least once, and that the DAs are subservient to this protocol. Owner: Anish Karmarkar Status: Open Assigned: 2005-09-27 Due: --- #0034: Abbie to raise new issue to have state diagram in the spec. Owner: Abbie Barbir Status: Open Assigned: 2005-09-27 Due: --- #0035: Chris F to Raise a new issue on whether text to resolve issue 9 is to be an assertion or parameter. Owner: Christopher Ferris Status: Open Assigned: 2005-09-27 Due: --- #0036: Tom to raise a new issue to align the main document text with resolution to issue 9. Owner: Tom Rutt Status: Closed Assigned: 2005-09-27 Due: --- #0037: Tom R to submit a concrete proposal to resolve Issue 008 for discussion by the TC members on the email list. Owner: Tom Rutt Status: Open – need to discuss issue 21 forst Assigned: 2005-09-27 Due: --- #0038: Chris F to provide a detailed proposal on issue 30 for voting by the TC. Owner: Christopher Ferris Status: Closed Assigned: 2005-09-27 Due: --- #0039: Marc G will ensure that the issue list contains pointers to the minutes discussion which carried the resolution. Owner: Marc Goodner Status: Open – Marc has done some of them Assigned: 2005-09-27 Due: --- #0040: Ashok to write proposed clarification text on meaning of “observed” in this spec. Owner: Ashok Malhotra Status: Open – Umit stated this may not necessary with the current version of the Policy spec Assigned: 2005-09-27 Due: --- #0041: Doug D will write new issue to characterize the piggybacking of acks when using an anonymous AcksTo Owner: Doug Davis Status: Open Assigned: 2005-09-27 Due: --- #0042: Umit will ask the WS-addressing group to discuss making anonymous URI description more generic. She will get back to us on their discussion Owner: Umit Yalcinalp Status: Closed, the ws addressing wg made the description more generic. She will send the text to the entire group. - Assigned: 2005-09-27 Due: --- #0043: Doug D to post alternative proposal, taking away the additional text in his original proposal on Issue 10. Owner: Doug Davis Status: Open Assigned: 2005-09-27 Due: --- #0044: Editors to incorporate proposed 04 from Seattle F2F as an edit to the draft. Owner: Status: closed Assigned: 2005-09-27 Due: --- #0045: editors to incorporate edits in Proposed 05 from Seattle F2F into draft spec Owner: Status: closed Assigned: 2005-09-27 Due: --- #0046: editors to incorporate proposed 11 from Seattle F2F into the draft spec Owner: Status: closed Assigned: 2005-09-27 Due: --- #0047: editors to incorporate propose 12 from Seattle F2F as editorial in draft spec Owner: Status: closed Assigned: 2005-09-27 Due: --- . 4 Committee Draft Status from Edting teamThere are so many new issues Marc G did not have time to prepare a summary for discussion. Anish posted two pdf docs, 05 version of ws-RM wd, and a diff of 05 version from initial submission version. Changes organized by Issue resolution are indicated in the document change log. Umit has incorporated all issue resolutions into a draft, which will be posted by the end of today, as two PDFs, one with change bars from initial, other with not change bars, and the change log is organized by issue number resolutions. Anish: we resolve the namespace problem for the first cd, with xx for months. We need to decide actual numbers for the published documents. Marc G: how long is the review period. Umit: two weeks. Tom R: the dates need to be fixed by the end of the two week review period. Dave: we agreed to vote on the meeting of the 20th. Paul: we can make editorial changes before the vote. Members should post any editorial comments to the editing team. The final deadline should be two days before the meeting on Oct 20. We can take a vote on October 20. Agreed to Use dates 2005/10 in Namespace URIs. Paul: I was planning to have the vote on the call. Quorum is 50 percent of voting members for normal CD. Tom Rutt: I propose that we schedule to have a vote on CDs at the Oct 20 meeting. If we do not make 51% quarum yes votes on the meeting of October 20, we can go to the fallback of a Kavi Ballot. Paul: perhaps it would be better to have a Kavi ballot starting on Oct 20, with one week. Agree: TC members need to get all editorial comments by Oct 18, and the kavi ballots will be initiated on the morning of Oct 20. 5 New Issues since last con callTwo new issues: 5.1 Tom Rutt New Issue on DA Alignment and refinementhttp://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00015.html Tom Rutt reviewed the issue, stating that the difference involve the raising of error conditions for At most once and Exactly once. Agree to add new issue. Tom Rutt accepted ownership 5.2 Stefan New issue on Delivery Assurances and their relation to the protocol.http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00269.html The possible solutions are to take out delivery assurances from the protocol document. Agreed to accept as new issue. Marc G accepted ownership. 6 Issue Discussion6.1
Issue 30: What are
the obligations on RMD for use (or not) of Offered Sequence?
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00274.html Mail from Chris F: All, The following is a proposed resolution to i030, to allow an RMD to effectively ignore an offered sequence yet at the same time, provide for the RMS to know when it can safely reclaim the resources with the "unused" offered Sequence. Since i001 has already been resolved [2], it is not necessary to address that aspect (whether the wsrm:Offer is required under certain circumstances). All that is left to address is how to provide the RMS with an indication that the offered Sequence is being ignored by the RMD. Proposal: Remove lines 545-546 of WS-RM spec (pdf) [3] so as to not require that the RMD send a wsrm:Accept in a CSR for a CS with a wsrm:Offer. Absence of a wsrm:Accept in a CSR for a corresponding CS with wsrm:Offer enables the RMS to safely reclaim the resources associated with the offered sequence. It isn't clear to me that the spec need to say anything about that, but if some would prefer it did, I offer this addendum to my proposal to be inserted immediatly following the deleted lines above: Note: If a wsrm:CreateSequenceResponse is returned without a child wsrm:Accept in response to a wsrm:CreateSequence that did contain a child wsrm:Offer, then the RM Source MAY immediately reclaim any resources associated with the unused offered Sequence. [1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14682/ReliableMessagingIssues.xml#i030 [2] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14682/ReliableMessagingIssues.xml#i001 [3] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14603/wsrm-1.1-spec-wd-03.pdf Cheers, Chris summarized the proposal: Anish: you had two options before, one had a decline. I am happy either way but want to be clear. Does absence of an Accept mean the same as Decline, rather than Unknown. Chris F: The absence of accept is a decline. Chris F Moved to accept proposal as written to remove lines as in his proposal for I030, and to add the note in his proposal., Seconded by Gil. § No objection motion to close issue I30 with chris F proposal passes. 6.2
Issue 48: CloseSequenceResponse and Acks
Description Using the CloseSequence operation a RMS will be able to get the true final accounting of the ACKs for a sequence - sort of. There is one case that could be problematic. Let's say that the CreateSequence operation is given a bad AcksTo EPR. In this case no Acks will ever be received by the RMS - and this could be the reason for it closing the sequence. However, if all ACKs are always sent to the AcksTo EPR then the RMS will have no choice but to eventually Terminate the sequence (or wait for it to timeout) without ever getting the true final accounting of Acks. This would leave the RMS and RMD with a very different view of the state of the sequence.
Proposal 12005-09-21 To solve this I'd like to require that the CloseSequenceResponse message include the "final" Ack. So, using [1]: Replace the text on line 608: Upon receipt of this message the RM Destination MUST send a SequenceAcknowledgement to the RM Source.
With: Upon receipt of this message the RM Destination MUST send a SequenceAcknowledgement to the RM Source in the CloseSequenceResponse message. Doug presented the proposal above: Anish: does this relate to acks to going bad. Gil: this is not the only case for doing this. There are any number of reasons you might not be getting Acks. When things get ugly, back off to the safest way. Sanjay: is close sequence response a message, while sequence ack is a header block. Sanjay: so you mean the sequence ack is in the header of body. Doug: the intent is that the sequence ack is in the header, for the envelope containint the close sequence response message. Paul: how does this relate to terminate sequence. Doug: since it is a oneway, it does not have a response, to it is not of concern. Paul: what about a terminate sequence response? Doug: that would be another issue however, the sender is not ready to do anything once it issues the terminate sequence. Anish: I suggest the sequenceAcknowledgement is the “last” one. Can this change be added to it. Doug D: I can do that. Doug D: motion to accept Doug Proposal to resolve Issue 048, with adding clarification that “final” is used, and to clarify it is a header and not going in the body, and that it does not replace Acks to., Seconded by Becky. Jacques: there are some errors in the current spec text regarding acks to.637 and 638 Doug D: I will take an action to fix that error in the text. § No objections to accepting proposal to resolve Issue 048. Ř Action: Doug D to fix editorial error in lines 637 and 638 of spec. 6.3
Issue 24: WS-RX
policies not manifested on the wire
Ashok stated he can provide replacement text for next week meeting. Umit: Do we still need to make a reference to ws-policy old version. Ashok: no we do not. We can edit the document to use proper terminology. Umit: I thought we were going to explain what observed meant, not to add a new attribute. Ashok: your document does not use the word Observed. Anish: the problem is using the work replacement text. Ashok: I mean additional text to explain things better. Jacques: I do not understand why we need to annotate the message with policy ID? I would like to see more argumentation on why sending policy on the wire would be a good thing. Paul F: The policy spec has wording about visible on the wire, this was the way to specify that they were “observed” as opposed to “visible on the wire”. I am not sure it is related to the client policy. Umit: Issue number 6 is different than what this issue is talking about. Umit and Ashok will work on a resolution for this issue. 6.4
Issue 21: An RM
Policy applies two-way
The issue is not up to date, I sent a later characterization: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00264.html i021
freshened a bit: Description: Last sentence of Section 2 in
RM-Policy spec says that an RM policy MUST apply to all messages in a binding
(when associated to binding). That means applying equally (same timing
parameters, etc.) to both in and out messages of an operation of type request-response.
However, clearly the DA requirements are different for each endpoint (Client
and WS), and so are the performance requirements and capabilities regarding the
protocol. For example, a WS may need ExactlyOnce for
incoming messages, and consequently implement the protocol along with its
receiving functions (sending Acks), but not willing
to implement the RM sending functions (resending mechanism...) - or at least
not with the same parameter values - if the responses need not be reliable. In
addition, when deployed in a WS-I-compliant (Basic Profile) environment, a
reliable Response has to be sent over an HTTP response. The RMS behavior (which
is now the sender of the Response) would need to implement a much more
constrained and context-dependent resending mechanism, as response messages can
only be resent as responses to request resendings.
Justification: Enforcing same protocol policies for
inbound and outbound messages may create unnecessary burden to a WS endpoint
for which RMD-only functions are sufficient. In addition, the resending
behavior for synchronous responses being more constrained, cannot obey the same
parameters. Proposal: A couple of proposal directions (either
/ or): 1. Assert somehow that RM policy
assertions are "oriented" by default, i.e. only apply to all
"in" messages from a Client to a WS endpoint unless specified
otherwise. 2. Attach policy assertions at
message level if needed (or provide means to override at message level, e.g.
attach a "void" policy to an out message, if no reliability needed
here.) Ashok: I thought binding applied to a particular message. Umit: the endpoint will apply to all the operations in the binding. Tom: does the spec now imply the same protocol and parameter apply to both request and response messages. We may need to have more detailed policy attachment to messages in Bindings. Ashok: In the submission spec, the scope of rm assertion is endpoint subject. What was the original intent, was it for all messages in that port type?. Also what does WS-policy state about putting assertions on binding or endpoint. Doug B: Another way to look at this question is to ask whether the assertions such as retry interval, are intended to constrain the client for a wsdl endpoint, or describe the way that that endpoint will reply. Glen D: That is the question with this issue. Doug B: It depends on how the policies are attached. Tom: does the attachment against the endpoint means it applies to all operations, then does it reply to reliability for the responses to those operations as well. Paul F: I agree that many times reliability on response is not a requirement. Glen D: we could write assertions in both directions, I need, vs I offer. Umit: question is whether message is where policy statements are attached or do we have another way to do it with endpoint attachments. Paul F: we need a concrete proposal for this and perhaps issue 008. We should have email discussions. Bob F: when we talk about timing parameters we are getting into issue 22 Turf as well. Tom and Jacques agreed to initiate an email discussion on this subject. 6.5
Issue 8: Policy
assertions granularity
No time to discuss 6.6
Issue 6: Source
based delivery QoS policy assertion
No time to discuss 7 New BusinessMeeting adjourned at 5:33 PM Eastern Time. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]