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

Ram,

First off, Doug was talking about "generating an UnknownSubscription 
fault" and you are talking about "returning an UnknownSubscription 
fault". As we are discussing on another thread, "generate" means "stop 
processing, log an error, and (optionally) transmit a fault message". 
Therefore you don't need to say "MAY generate" to indicate the 
optionality of transmitting a fault message. "MUST generate" means "you 
MUST stop processing, you MUST log an error, and you MAY transmit a 
fault message".

Other comments inline . . .

On 12/31/2009 3:51 PM, Ram Jeyaraman wrote:
>
> 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.
>
<gp> Regardless of whether or not a Subscription Manager persists the 
history of every subscription it must, at a bare minimum, store the 
state of every active subscription or it simply won't work. Therefore, 
when it gets a request (getstatus, renew, unsubscribe) for a 
subscription that it doesn't have a record of, it has enough information 
to generate the UnknownSubscription fault.</gp>
>
> 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.
>
<gp> This is an interesting case, and I think we need to actually 
describe it in the spec. Right now we just say "If the subscription is 
not active, the request MUST fail and the subscription manager . . ." 
That sentence presumes that the request actually reaches the 
subscription manager.
>
>  
>
> 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.
>
>  
>
>  
>