This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There are three spots in ws-eventing where it says: -- If the subscription is not active, the request MUST fail and the subscription manager MAY generate a wse:UnknownSubscription fault. -- Its not clear to me why the MAY isn't a MUST. It seems we should pick one fault so that people know what to expect. If the idea here is that the subscription could be in some state where its not totally dead yet and therefore might not be "Unknown", then I wonder why we care? If the client can't do anything with the subscription in this state then what difference will it make if its "Unknown" or "Dying"? Unless the protocol wants to define this "in between" state (which means we need to define this state, and a new fault to be returned) we have an interop problem because now some impl-specific fault will be generated for a common situation. And I believe our state tables are consistent with this too. Proposal: s/MAY/MUST/ in all 3 cases (renew, getstatus, unsubscribe)
research in the Hursley minutes to see if already specifically discussed
Latest proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jan/0045.html
resolved with comment Nr. 2 plus spelling corrections