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

Gil wrote:
> Ram wrote: 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.

Yes this is an interesting one.  Clearly if the incoming message never
even makes it to the Eventing implementation then we have no control
over it.  However, that also means that we can't mandate anything, 
incluging that that the request fail - so the "MUST" in the current 
text is inappropriate.

What I think we should probably do on this issue is one of two things:
1 - follow WS-Transfer's lead and say nothing about the situation where
    a message is sent to a dead EPR - so remove the text and fault.

2 - modify the text so that it says something along the lines of:
    If a request message reaches an conformat implementation of 
WS-Eventing,
    and the message refers to a unknown Subscription, then the 
implementation
    MUST generate a wse:UnknownSubscription fault.
 
    And, add this same type of thing (text and fault) to WS-Transfer. 
    Yes that darn consistency thing again. 

However, we first need to accept the issue.

-Doug

> 
> 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
>         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.
> 
>