This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 8176 - Eventing: MAY vs MUST on UnkownSubscription fault
Summary: Eventing: MAY vs MUST on UnkownSubscription fault
Status: CLOSED REMIND
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: Eventing (show other bugs)
Version: FPWD
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Doug Davis
QA Contact: notifications mailing list for WS Resource Access
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 8283
  Show dependency treegraph
 
Reported: 2009-11-04 15:00 UTC by Doug Davis
Modified: 2010-03-17 11:31 UTC (History)
0 users

See Also:


Attachments

Description Doug Davis 2009-11-04 15:00:45 UTC
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)
Comment 1 Robert Freund 2009-11-06 23:56:38 UTC
research in the Hursley minutes to see if already specifically discussed
Comment 3 Robert Freund 2010-01-12 21:04:08 UTC
resolved with comment Nr. 2 plus spelling corrections