This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0027.html
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) -Oliver
Created attachment 760 [details] Proposal that includes the use of the @Minimum attribute.
[Action] http://www.w3.org/2009/09/ws-evt/Subscribe [Body] <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> ? xs:any* </wse:Subscribe> The Following replaces [Body]/wse:Subscribe/wse:Expires and the paragraphs following. [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 <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 indefinite. This will also be applied to renew
resolved with comment #4