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 9702 - Eventing: Add a wse:ExpirationTimeConstraintsNotSupported fault
Summary: Eventing: Add a wse:ExpirationTimeConstraintsNotSupported fault
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: Eventing (show other bugs)
Version: LC
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: notifications mailing list for WS Resource Access
QA Contact: notifications mailing list for WS Resource Access
Keywords: externalComments
Depends on:
Reported: 2010-05-10 20:36 UTC by Antoine Mensch
Modified: 2010-07-28 09:09 UTC (History)
3 users (show)

See Also:


Description Antoine Mensch 2010-05-10 20:36:58 UTC
Supporting the min, max and exact constraints on requested expiration time may be too complicated for small devices (especially since the semantics of comparison for xsd:duration is not particularly well defined  e.g. is 1 month greater than 30 days?). In addition, when using scarce resources, it is important to leave the responsibility of the subscription life cycle to the event source(as was the case in the Submission version of the spec). If this feature is profiled out by DPWS (OASIS Devices Profile for Web Services), DPWS may have to introduce a DPWS-specific fault, thus creating interop issues with standard WS-Eventing subscribers. Therefore, a standard fault for handling this case could be useful.
Comment 1 Li Li 2010-05-12 15:27:08 UTC
Please clarify the differences between the proposed fault and existing faults: wse:UnsupportedExpirationType and wse:InvalidExpirationTime.
Comment 2 Antoine Mensch 2010-05-12 16:03:05 UTC
wse:UnsupportedExpirationType addresses the case where a xsd:dateTime is used as expiration spec, when only xsd:duration is supported by the event source, so it is not related to my issue.
wse:InvalidExpirationTime means that the expiration spec is either malformed (i.e. not a xsd:dateTime or xsd:duration), or that it does not fulfill the constraints expressed by the @min and @max attributes (which by the way means that the event source understands those atributes).
wse:ExpirationTimeConstraintsNotSupported would be used to reject a subscription request using constraints when the event source is not able or not prepared to use them. As explained in the issue description, supporting those constraints might be a problem for small devices.  
I know that some people might claim that using faults is not the best way to discover if optional features are supported, but note that this is exactly what happens when wse:UnsupportedExpirationType is returned (this remark is not a request to remove this particular fault!)
Comment 3 Robert Freund 2010-05-12 19:04:09 UTC
directional decision Expires is server optional, add a fault for when its not supported, add a ExpiresSupported policy assertion, Subscribe w/o Expires == server chooses, Subscribe + Expires == match the time/duration or fault.
consider until 2010-05-13
Comment 4 Ram Jeyaraman 2010-05-13 01:10:13 UTC
Consequent to what we discussed today about simplifying the existing semantics for specifying a subscription expiry time, I like to propose the following refinement to what was discussed today [1]:

1) Expires is server optional, add a fault to indicate non-support, and add an ExpiresSupported policy assertion parameter.

2) If Expires is absent, server chooses an appropriate duration for subscription.

3) If Expires is present:

If attribute exact is present, the server must honor the requested duration or reject the subscription with a fault.

If the attribute exact is absent (default behavior) , the requested duration is a hint. This allows the event source to better accommodate the client preferences when it grants a time duration for subscription.

[1] Direction discussion today

Expires is server optional, add a fault for when its not, add a ExpiresSupported policy assertion, Subscribe w/o Expires == server chooses, Subscribe + Expires == match the time/duration or fault
Comment 5 Doug Davis 2010-05-13 17:47:31 UTC
Absent == indefinite, present == exact, present + @bestEffort=true == best effort, present/PT0S == indefinite/exact, present/PT0S+@bestEffort=true  == indefinite/best-effort

policy: DateTimeSupported, ExpiresSupported, MaxExpires

add Fault for cases where expires is not supported

applies to Renew too

editorial: reorder assertions so these grouped together
Comment 6 Robert Freund 2010-05-13 17:48:55 UTC
resolved with comment 5
Comment 7 Doug Davis 2010-05-13 18:04:11 UTC
apply to enum too