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

There are at least two ways to implement a Subscription Manager, and as a result there are a several possible fault outcomes while invoking operations on a SubscriptionManager whose subscription has ended:



*       Implementation choice #1: Only one Subscription Manager for all subscriptions

o   Outcome #1a: If the Subscription Manager does not persistently store subscription state, that is, it does not maintain persistent history of all the subscriptions, it may return an UnknownSubscription fault.

o   Outcome #1b: If the Subscription Manager persists subscription state, that is, it maintains persistent history of all the subscriptions, it may return a response indicating the status of the subscription.

*       Implementation choice #2: One Subscription Manager for each subscription

o   Outcome #2a: In this case, the SubscriptionManager may go away when the subscription ends. In such a case, a request message sent to a SubscriptionManager endpoint may result in a transport level fault.



When we discussed this during the October F2F [1], we concluded that it is sufficient to state that the SubscriptionManager MAY generate a UnknownSubscription fault when Renew/GetStatus/Unsubscribe operations are invoked. Hence, I suggest that we retain the exiting text.



This completes my AI relating to this issue.



Thanks.



[1] http://www.w3.org/2002/ws/ra/9/10/2009-10-01.html#item05



-----Original Message-----
From: public-ws-resource-access-notifications-request@w3.org [mailto:public-ws-resource-access-notifications-request@w3.org] On Behalf Of bugzilla@wiggum.w3.org
Sent: Wednesday, November 04, 2009 7:01 AM
To: public-ws-resource-access-notifications@w3.org
Subject: [Bug 8176] New: Eventing: MAY vs MUST on UnkownSubscription fault



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<mailto:public-ws-resource-access-notifications@w3.org>

        ReportedBy: dug@us.ibm.com<mailto:dug@us.ibm.com>

         QAContact: public-ws-resource-access-notifications@w3.org<mailto: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.