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 8832 - Eventing: spec unclear on sink/subscriber behavior in face of expected subscription expiration
Summary: Eventing: spec unclear on sink/subscriber behavior in face of expected subscr...
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: Eventing (show other bugs)
Version: LC
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Gilbert Pilz
QA Contact: notifications mailing list for WS Resource Access
Depends on:
Reported: 2010-01-27 22:58 UTC by Gilbert Pilz
Modified: 2010-07-27 20:24 UTC (History)
2 users (show)

See Also:

Proposed changes to Section 4 (306.83 KB, application/x-zip-compressed)
2010-04-05 18:35 UTC, Gilbert Pilz

Description Gilbert Pilz 2010-01-27 22:58:33 UTC
WS-Eventing says that subscriptions can expire. Fundamentally the Subscription Manager has the final word on whether or not a subscription has expired, but the Event Source has "some" knowledge of the expiration time. What SHOULD/SHOULDN'T, MUST/MUSN'T the Subscriber/Event Sink do with respect to this knowledge?

For example, during a Subscribe/SubscribeResponse exchange it is agreed on that the subscription will expire in exactly 30 minutes. By the Subscriber/Event Sinks clock, 45 minutes have elapsed since it has received the SubscribeResponse. What, if anything, should we say about this situation in the spec? For example, we could say (in the description of Renew - again for example) "The Subscriber/Event Sink SHOULD NOT send the Renew request in cases where, by its clock, the subscription has expired." Alternatively we could proactively assert that the Subscriber/Event Sink should not presume that it knows whether or not the subscription has expired.
Comment 1 Li Li 2010-02-16 21:19:35 UTC

Not quite sure why we need to restrain the client (subscriber) in this case - as it sounds more like a pious advice.

You said correctly that the server (subscription manager) has the final say and the client should alwyas rely on it. So the behavior is covered already.

If you think there is something missing, should we clarify server's behavior instead so that it works in this case?
Comment 2 Gilbert Pilz 2010-04-05 18:35:32 UTC
Created attachment 858 [details]
Proposed changes to Section 4

ZIP file with modified WS-Eventing HTML and PDF with change bars.
Comment 3 Robert Freund 2010-04-06 19:39:17 UTC
resolved as proposed in comment #2