[Bug 8832] New: spec unclear on sink/subscriber behavior in face of expected subscription expiration

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8832

           Summary: spec unclear on sink/subscriber behavior in face of
                    expected subscription expiration
           Product: WS-Resource Access
           Version: LC
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Eventing
        AssignedTo: public-ws-resource-access-notifications@w3.org
        ReportedBy: gilbert.pilz@oracle.com
         QAContact: public-ws-resource-access-notifications@w3.org


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.


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

Received on Wednesday, 27 January 2010 22:58:35 UTC