Next in thread →
Next in month →
Re: [ws-rx] Prelim Minutes of 3/9 Teleconf
Tom, I think: Doug D: I see this as mostly harmless. Was said by DougB not me - although I agree with the comment :-) -Doug Tom Rutt <> 03/09/2006 05:35 PM Please respond to tom To wsrx <> cc Subject [ws-rx] Prelim Minutes of 3/9 Teleconf Please post corrections before Monday morning Tom Rutt -- ---------------------------------------------------- Tom Rutt email: ; Tel: +1 732 801 5744 Fax: +1 732 774 5133 Prelim Minutes of OASIS WS-RX Teleconference March 09, 2006 Start Time:4:00 PM Eastern Time Paul Freemantle acted as chair. Textual Conventions Ø Action Item Motion § Resolution 1 Roll Call From Kavi: xx of 52 voting members, meeting quorate Tom Rutt agreed to take minutes. 2 Agenda Approval 1) Roll Call 2) Review and approval of the agenda 3) Approval of the Mar 2nd, 2006 meeting minutes 4) AI Review 5) Editors update CD 2 and CD 3 posting etc 6) Raleigh F2F Planning a> Dial-in sponsorship b> Update from Doug on facilities c> Any other issues d> Post F2F timeline 8) New issues since last conf-call Watch for Marc’s email 9) Issue Discussion: a> i101 Recommend RMD Close rather than Terminate http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i101 b> i098 clarify difference between "sequence" and "non-sequence" faults http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i098 c> i099 Correlating faults to Sequences using SOAP 1.1 http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i099 d> i090 Use of offered sequences unclear in current spec http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i090 e> i089 suggest the restricted use of anonymous URI http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i089 f> i021 An RM Policy applies two-way http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i021 g> i008 Policy assertions granularity http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i008 9) Any other business Paul F stated the implementation SC had discussion on issue 89. Paul would prefer to move issue 89 to end of agenda. Dan Millwood asked that we have a review of the discussion of the SC on 89 first. Agreed to limit discussion on 89. 3 Approval of the 3/2 minutes; http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/17061/MinutesWSRX-030206.html Tom moved and Marc G seconded. § Minutes approved by unanimous consent. 4 Action Items http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php #0056: Ensure that the final WSA specifications include text for handling of anonymous IRI values for non-WSA EPRs Owner: Robert Freund Status: Open Assigned: 2005-12-13 Due: --- Bob F: ws addressing group is proposing final text to w3c. There were changes around the earlier resolution to issue cr004 from ws-rx regarding anonymous URI. This will be sent to the group. Tom: the ws addressing group is no longer suggesting reuse of the anonymous uri. However they do not explicitly prohibit it. #0085: Paul F to write up a more detailed proposal to Proposed 06 from 3/2 Owner: Paul Fremantle Status: closed Assigned: 2006-03-06 Due: --- #0086: Chris F to provide further rational text for his proposal for I021 Owner: Christopher Ferris Status: closed Assigned: 2006-03-06 Due: --- #0087: Anish provide explanation of the desired semantics for I 021 Owner: Anish Karmarkar Status: closed Assigned: 2006-03-06 Due: --- 5 Editors update CD 2 and CD 3 posting etc Doug D: CD 3 has not been completed. Paul F: we need to update our committee draft folder. It currently lists cd 1. The public page only lists CD1. We need to ensure CD 2 and CD3 are in the proper folders in the public and private home page. Ø Action: Doug D will post CD2 and CD3 artifacts on the Kavi Site, with appropriate public page links. Work with OASIS staff to get public posting. Ø Action: Paul F will give Doug D secretary status on Kavi. Paul C: we have to be sure the namespaces are updated. Paul C: the namspaces seem tied to the CD number. We should be able to keep namespaces constant between CDs. Ø Action: Gill will ensure the proper file name for the namespace document. 6 Raleigh F2F Planning 6.1 Dial-in sponsorship TIBCO volunteered for another period for the call. Shivaji: who do I give the call in info to. Paul F: send it to me, also the volunteers from the last week minutes should send me the call in details. 6.2 Update from Doug on facilities 37 percent has still not voted. Doug stated there will be continental breakfast, Lunch and afternoon snack. There is planned to be network connectivity. However there will not be incoming endpoints available. Paul C: will this affect interop. Paul F: Doug should send a note to the interop SC to see if this may be a problem. 6.3 d> Post F2F timeline Paul F: we have a tight timeline after this face to face meeting. We can adjust these dates at the face to face. We wanted to have a public review early in April. Marc G: I have heard about another interop round. Paul F: the SC has discussed a public round with identified endpoints, after the public review draft is sent out. The first interop is the one which is expected to find issues on the spec. Marc G: when will we have F2F agenda, and it should include interop feedback on the first day. Paul F: any suggestions for agenda should be send to Paul F and Sanjay. 7 New issues since last conf-call Watch for Marc’s email None 8 Issue Discussion: 8.1 i101 Recommend RMD Close rather than Terminate http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i101 Paul F posted http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200603/msg00050.html Based on CD3/WD10 At Line 365 insert the following sentence at the period. For example, a client program may be in the process of being terminated; a business application timeout may mean that there is no reason to continue delivering undelivered messages; or a server may wish to timeout an sequence that has not been used recently. At line 367/368 replace the final sentence of the paragraph with: To ascertain the final state of the sequence the RM Source MAY choose to close the sequence before terminating it. At line 381/382 replace the first sentence of the paragraph with: In the case where the RM Destination wishes to discontinue use of a sequence it SHOULD close the sequence rather than terminate it, allowing the RM Source to ascertain the final state of the sequence. Bob F: on closure sequenceAckFinal is sent. I have a concern about “state of delivery” of messages. If an RMD has implemented ordered delivery, and if there is a message out of order, there is an expressing of missing message. However the application would not receive all of that, only up to the gap. Paul F: I think this is worth point out as a new issue, however it is different than this one. Tom R: I agree we could file a new issue on clarifying use with deliver status vs received status. Implementations would likely make the waiting messages available to the receiving application at termination time. Doug D moved to accept proposal for issue 101, Tom R seconded. § No opposition, proposal for issue 101 accepted. 8.2 i098 clarify difference between "sequence" and "non-sequence" faults http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i098 Gil posted proposal at: http://lists.oasis-open.org/archives/ws-rx/200603/msg00063.html The lines 659-663 in http://www.oasis-open.org/committees/download.php/16851/wsrm-1.1-spec-wd-10.pdf (excluding the first word of the sentence starting with "Sequence faults SHOULD . . .") should be changed to read: The faults defined in this section fall into one of two categories; those faults that are the result of messages or operations within a specific Sequence and those faults that are not. By their nature the CreateSequenceRefused, UnknownSequence, and WSRMRequired faults cannot be correlated with a Sequence. All other faults defined in this section relate to the processing of WS-RM protocol messages or messages containing WS-RM header blocks targeted at a specific Sequence and are collectively referred to as "sequence faults". Chris F moved to accept proposal from Gil to resolve i098, seconded by Charleton. Doug B: why are we making this distinction. Gil: you have to ensure the entity is authorized for the sequence. Doug B: I understand why implementations need to treat messages and faults according to security policy, however I an not clear where this distinction needs to be made in the spec. Gil: are you proposing a different solution. Doug B: I am asking why we need to say anything about this. Perhaps we can delete the text referring to sequence faults. Gil: I would favor this change now, and have future issues raised as required. Paul F: the spec already uses the term sequence faults, this adds a clarification of that term. Doug D: I see this as mostly harmless. § No objections, issue i098 resolved with Gil’s proposal. 8.3 i099 Correlating faults to Sequences using SOAP 1.1 http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i099 Gill proposal posted as: http://lists.oasis-open.org/archives/ws-rx/200603/msg00064.html With reference to http://www.oasis-open.org/committees/download.php/16851/wsrm-1.1-spec-wd-10.pdf: After line 710 insert: <wsrm:Detail> [Detail] </wsrm:Detail> Change lines 738-741 (<wsrm:SequenceFault> exemplar) to: <wsrm:SequenceFault ...> <wsrm:FaultCode> wsrm:FaultCodes </wsrm:FaultCode> <wsrm:Detail> ... </wsrm:Detail> ? </wsrm:SequenceFault> After line 746 insert: /wsrm:SequenceFault/wsrm:Detail This optional element is intended for carrying application specific error information related to the fault being described. /wsrm:SequenceFault:/wsrm:Detail/{any} The application specific error information related to the fault being described. (corresponding changes to wsrm-1.1-schema-200602.xsd left as an exercise for the monkeys) Chris F moved, Doug D seconded to resolve I099 with Gil’s proposal. § No objection, accept Gill’s proposal to resolve I099, mark as pending. 8.4 Discussion from interop SC Paul F discussed an issue about the interop scenarios, regarding the anonymous URI. Paul F: two issues. In order to get a missing response message, it is required to resend the actual request messages for which that is a response to. This is not written down. Tom R: why does the rms have to save after it gets an Ack. Paul F: the problem is the response might be lost. The request was acked so the rms could delete the request. However to get the response again the rms has to resend the request, even after it acked. Gil: this is only a problem in synchronous case when rm semantics are applied to response. Glen D: this raises a concern, if you do not know if something other than rm machinery will occur. It requires duplicate elminiation in some business cases. The sender needs to know if ther will be duplicate detection. Paul F: how is this different than rm in a one way case Glen D: you might resend either way. Tom R: I agree that to make this work both sides need to know what is going on. Our sister WSRM TC has be discussing how to do reliability on synchronous response for a while. It requires both sides to know there is reliability on synchronous response. We could add things to our protocol to make such knowledge available. We could use extra information on the Create Sequence to exchange this knowledge. Chris F: In this case, the response must be carried on the http response. To carry the response again you have to resend the message. There was considerable discussion on the repercussions of this apparent dilemma. Paul F: other points need to be made. The 2.4 scenario from Microsoft, talks about timing of when acks are delivered back. Paul F: regarding Tom’s point, I agree that both sides need to know what is going on. The offer cannot be treated as an uncorrelated sequence. We need to add words that has special semantics in the request/response binding to soap. The Apache stack cannot yet handle this, because it deletes on receipt of the ack. Doug D: if this scenario causes problems, we could take it out of the test cases. Dave O: is the question for this upcoming interop event, or the follow on event. If it is only for this event, the case could be dropped. It can be added later after the TC has concensus. Paul C: we need solid pointers to the documents being discussed. Having this on this interop gains us more data. If we successfully interop on this scenario, we can gain knowledge. Why drop it on this list of things. It does not have to be implemented by all. Tom R: this is related to the I021 discussions. If the default on a request response endpoint is reliability for both request and response, we have to have the mechanisms in place to make this happen. We could decide to not require reliability in response. If reliability in response is required, the sender must do extra buffering beyond the first ack. Further discussion ensued on the assumptions on behavior for this scenario which are not written down, with respect to the interop scenarios taking place. Meeting closed at 5:32 pm. Eastern time. _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Next in thread →
Next in month →