This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
Please clarify the differences between the proposed fault and existing faults: wse:UnsupportedExpirationType and wse:InvalidExpirationTime.
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!)
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
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
Proposal: 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
resolved with comment 5
apply to enum too