8176 2009-11-04 15:00:45 +0000 Eventing: MAY vs MUST on UnkownSubscription fault 2010-03-17 11:31:50 +0000 1 1 1 Unclassified WS-Resource Access Eventing FPWD PC Windows XP CLOSED REMIND P2 normal --- 8283 1 dug dug public-ws-resource-access-notifications oldest_to_newest 29301 0 dug 2009-11-04 15:00:45 +0000 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) 29433 1 bob 2009-11-06 23:56:38 +0000 research in the Hursley minutes to see if already specifically discussed 30841 2 dug 2010-01-10 13:01:23 +0000 Latest proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jan/0045.html 30994 3 bob 2010-01-12 21:04:08 +0000 resolved with comment Nr. 2 plus spelling corrections