W3C home > Mailing lists > Public > public-ws-resource-access-notifications@w3.org > November 2009

[Bug 8176] New: Eventing: MAY vs MUST on UnkownSubscription fault

From: <bugzilla@wiggum.w3.org>
Date: Wed, 04 Nov 2009 15:00:45 +0000
To: public-ws-resource-access-notifications@w3.org
Message-ID: <bug-8176-2780@http.www.w3.org/Bugs/Public/>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:36 UTC