9702 2010-05-10 20:36:58 +0000 Eventing: Add a wse:ExpirationTimeConstraintsNotSupported fault 2010-07-28 09:09:54 +0000 1 1 1 Unclassified WS-Resource Access Eventing LC PC Windows XP CLOSED REMIND externalComments P2 normal --- 1 antoine.mensch public-ws-resource-access-notifications dug lli5 ram.jeyaraman public-ws-resource-access-notifications oldest_to_newest 35542 0 antoine.mensch 2010-05-10 20:36:58 +0000 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. 35627 1 lli5 2010-05-12 15:27:08 +0000 Please clarify the differences between the proposed fault and existing faults: wse:UnsupportedExpirationType and wse:InvalidExpirationTime. 35631 2 antoine.mensch 2010-05-12 16:03:05 +0000 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!) 35647 3 bob 2010-05-12 19:04:09 +0000 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 35661 4 ram.jeyaraman 2010-05-13 01:10:13 +0000 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” 35677 5 dug 2010-05-13 17:47:31 +0000 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 35678 6 bob 2010-05-13 17:48:55 +0000 resolved with comment 5 35679 7 dug 2010-05-13 18:04:11 +0000 apply to enum too