This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Past experience has shown that state tables are a useful tool for describing how to manage shared resources such as the Subscription defined in WS-Eventing. There should be two tables in the specification; one that describes the Subscriber's point of view and the other that describes the point of view of the Event Source/Subscription Manager. Each table should enumerate all the possible states of a Subsciption and list the acceptable request or response messages for that state and the resulting state transition(s) (if any). The addition of these tables will improve our chances of detecting interoperability issues.
proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0032.html
Created attachment 805 [details] version 6 of WS-Eventing state tables proposal
Created attachment 807 [details] version 7 of the WS-Eventing state tables proposal
Created attachment 810 [details] version 8 of the WS-Eventing state tables proposal Removed "generate fault" defaults for unspecified Action/State cells. Changed RenewResponse/End cell and Expiration/Renewing cells to record the fact that, if the expiration timer goes off while awaiting a renew response the Subscriber/Event Sink should consider that Subscription to be in the "End" state but, if the subscription is in the "End" state an a RenewResponse arrives, the subscription should go back to the "Active" state.
Created attachment 819 [details] state tables as discussed at f2f
Resolved with comment #5 and the provision that client side tables will be constructed by the editor