6692 2009-03-12 15:37:27 +0000 WS-Eventing: Remove Mode from the specification 2009-09-16 08:12:47 +0000 1 1 1 Unclassified WS-Resource Access Eventing FPWD PC All CLOSED REMIND hasProposal P2 major --- 6432 1 david.Snelling david.Snelling asirveda dug lli5 public-ws-resource-access-notifications oldest_to_newest 24211 0 david.Snelling 2009-03-12 15:37:27 +0000 The concept of Mode is redundant in the current version of the specification. All events can be thought of as being delivered. There is no actual definition of "Push Mode" and no other recommended modes. We even have a MakeConnection strategy to allow clients behind NATs to fetch events. Likewise, strategies for complex queuing and distribution are supportable without adding additional modes and are outside the scope of this specification. Proposal: Remove /s:Envelope/s:Body/*/wse:Delivery/@Mode from the specification and all references to Push Mode. A simple explanation of the delivery idea and a pointer to some of the techniques available will be needed. 24345 1 lli5 2009-03-20 13:52:57 +0000 Definition of "Push Mode" is in section 3.3: Push Mode A delivery mechanism where the source sends event messages to the sink as individual, unsolicited, asynchronous SOAP messages. Please also see http://www.w3.org/Bugs/Public/show_bug.cgi?id=6428 for a proposed change. 24400 2 bob 2009-03-24 21:33:20 +0000 discussed at length on 2009-03-24 24401 3 bob 2009-03-24 21:45:19 +0000 dependency not agreed at 2009-03-24 meeting 24497 4 asirveda 2009-04-02 05:33:49 +0000 A description of why delivery mode is needed can be found at: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0132.html 24964 5 bob 2009-04-28 21:23:43 +0000 Action-63 25539 6 bob 2009-06-10 23:17:06 +0000 directional decision achieved Mode attribute is removed replaced with a collection of QNames extension elements scoped to the children of their parent extension elements put in the "right" place" delivery or stamp or some-such wrapper to contain extensions and parameters delivery tentatively and roughly defined as "the collection of rules and parameters for the conveyance of notification messages from source to sink" (which may need more work) Agreed that the notion of delivery will be maintained and represented by the above wrapper agreed that future work is needed to tighten up faulting agreed that future work is needed for subscribe response At least one member feels that future work might be needed to scope extensions to EndTo. In any case the mode attribute has been replaced with another mechanism (action 70 on Geoff) 25827 7 bob 2009-06-30 11:16:40 +0000 interim proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0052.html 25835 8 dug 2009-06-30 20:13:16 +0000 And another proposal: http://www.w3.org/2002/ws/ra/9/06/wseventing-DeliveryElement.html 26056 9 bob 2009-07-24 09:56:00 +0000 proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/att-0057/wseventing-6692-10.doc 26114 10 bob 2009-07-29 14:58:47 +0000 2009-07-28: Proposal in comment 9 accepted with the following amendments: In the sentences: "The absence of any extensions to the wse:Delivery or wse:NotifyTo elements indicates that notifications should be asynchronously sent as SOAP messages to the endpoint described in lines (21-28). " and "When present this element indicates that notifications MUST be asynchronously sent to the EndpointReference identified by this element." delete teh word "asynchronously" change the sentence: "This specification defines only an asynchronous method of delivery for notifications from the event source to event sink." to "This specification defines a method for transmitting notifications from the event source to the event sink through the use of thew se:NotifyTo element."