- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 04 Nov 2009 15:00:45 +0000
- To: public-ws-resource-access-notifications@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8176 Summary: Eventing: MAY vs MUST on UnkownSubscription fault Product: WS-Resource Access Version: FPWD Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Eventing AssignedTo: public-ws-resource-access-notifications@w3.org ReportedBy: dug@us.ibm.com QAContact: public-ws-resource-access-notifications@w3.org 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) -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug.
Received on Wednesday, 4 November 2009 15:00:54 UTC