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 7478 - Eventing: subscription expiration negotiation is incomplete and inefficient
Summary: Eventing: subscription expiration negotiation is incomplete and inefficient
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: Eventing (show other bugs)
Version: FPWD
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Gilbert Pilz
QA Contact: notifications mailing list for WS Resource Access
Keywords: hasProposal
Depends on:
Reported: 2009-09-01 18:43 UTC by Gilbert Pilz
Modified: 2009-12-08 22:15 UTC (History)
2 users (show)

See Also:

Proposal that includes the use of the @Minimum attribute. (113.81 KB, application/pdf)
2009-10-01 15:19 UTC, Gilbert Pilz

Description Gilbert Pilz 2009-09-01 18:43:39 UTC
The current mechanism in WS-Eventing for negotiating subscription expiration is incomplete and inefficient. The Subscriber should be able to specify any of the following constraints:

1. I don't care what the expiration time is - I can live with whatever the Event Source decides.

2. I need an expiration time that is no less than X.

3. I need a Subscription that does not expire.

The Event Source should either create a Subscription within these constraints or fault.

Currently WS-Eventing treats the Subscribers expiration constraints as advisory. Regardless of the absence/presence or value of the wse:Expires in the wse:Subscribe request, the Event Source is free to create a Subscription with any expiration value it sees fit. This leaves the Subscriber with no recourse other than to examine the /wse:SubscribeResponse/wse:Expires value (if such exists) and Unsubscribe if it can't accept this value. This is inefficient both in terms of coding as well as the runtime and resource costs of creating a Subscription that is then immediately Unsubscribed-ed by the Subscriber.
Comment 2 Oliver Newell 2009-09-24 05:04:08 UTC
Is the primary intent of the expiration time to allow the server to gracefully age out clients subscriptions when clients go away for whatever reason? I think that was the case with GENA, which was a precursor to WS-Eventing (now limited to use in UPnP it seems).

My experience is that for the most part clients want data until they no longer want it, and they will not always be well behaved and do a clean unsubscribe when they are done. Having an expiration time that is determined server side and requiring a client to renew ever so often handles this case in a practical way from the server's perspective. If a client needs an expiration that doesn't expire, it's not a big burden on a client to have to refresh the subscription every so often (UPnP device manufacturers typically set the timeout between 15-30 min when they grant subscriptions), and it makes life for the server implementer much simpler and more manageable. There's no guesswork from the server perspective trying to figure out if a client is still actively listening to a subscription or not (which is hard/impossible for middleware that is connectionless on transmit)

One way to think about it is that the Web scales so well because it is stateless for the most part. Subscriptions aren't stateless, but at least we can put a time window on the 'statefullness' to minimize the impact. In my opinion, that is the intent of the expiration time more so than communicating information about how long the client actually is interested in the data. That's almost a separate issue. 

So I guess I would say proceed with caution w/respect to item 3.
With the exception of email-type subscriptions, I would say servers would not want to support it due to the resource management issue (so errors would be a common return for that type of request)


Comment 3 Gilbert Pilz 2009-10-01 15:19:46 UTC
Created attachment 760 [details]
Proposal that includes the use of the @Minimum attribute.
Comment 4 Robert Freund 2009-10-02 14:12:58 UTC

  <wse:Subscribe ...>
    <wse:EndTo> endpoint-reference </wse:EndTo> ?
    <wse:Delivery ...> xs:any* </wse:Delivery>
    <wse:Format Name="xs:anyURI"? > xs:any* </wse:Format> ?
    <wse:Expires min="(xs:dateTime | xs:duration)"? max="(xs:dateTime |
xs:duration)"? exact="xs:boolean"?>
        (xs:dateTime | xs:duration) 
    </wse:Expires> ?
    <wse:Filter Dialect="xs:anyURI"? ...> xs:any* </wse:Filter> ?

The Following replaces [Body]/wse:Subscribe/wse:Expires and the paragraphs

[Body] /wse:Subscribe/wse:Expires

This OPTIONAL element can be used by the Subscriber to indicate the expiration
time of the requested Subscription. The value of this element indicates the
desired expiration time for the subscription. The implied default is indefinite
(no expiry). The value of this element MUST be between the values of the @min
and @max attributes inclusive. If the request is malformed, the event source
MUST generate a wse:InvalidExpirationTime fault.

If the wse:Expires element is present and the event source is not able to grant
an expiry time within range indicated by the @min and @max attribute values, it
MUST generate a wse:ExpirationTimeExceeded fault. 

[Body] /wse:Subscribe/wse:Expires@min

The implied default is PT0S. This specifies the minimum expiration time that
the event subscriber is willing to accept.

[Body] /wse:Subscribe/wse:Expires@max

The implied default is indefinite (no expiry). This specifies the maximum
expiration time that the event subscriber is willing to accept.

[Body] /wse:Subscribe/wse:Expires@exact

The default value is "false" in which case this attribute has no effect. If
this attribute value is "true" both @min and @max attributes MUST be ignored
and are treated as if they had the same value as the wse:Expires element.

Need a new response type wse:GrantedExpires

        (xs:dateTime | xs:duration) 
    </wse:GrantedExpires> ?

The value of this element indicates the expiration time (or duration) granted
by the event source. If this element is missing the granted expiration time is

This will also be applied to renew
Comment 5 Robert Freund 2009-10-02 14:13:23 UTC
resolved with comment #4