- 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