11703 2011-01-09 02:15:13 +0000 Eventing: error on bad filter expression 2011-09-13 21:29:32 +0000 1 1 1 Unclassified WS-Resource Access Eventing CR PC Windows XP CLOSED REMIND P2 normal --- 1 dug public-ws-resource-access-notifications public-ws-resource-access-notifications oldest_to_newest 43950 0 dug 2011-01-09 02:15:13 +0000 43951 1 dug 2011-01-09 02:20:32 +0000 Eventing and Enum deal with filters slightly differently. In particular, enum has this text under the definition of "Filter": ==== If the data source supports filtering and the requested dialect but cannot process the requested filter content, the request MUST fail, and the data source MUST generate a wsen:CannotProcessFilter fault. ==== In cases where the filter expression is bad (e.g. a syntax error) I believe that the above text in enum will case a wsen:CannotProcessFilter fault to be generated. However, I don't see a similar fault defined for eventing. This leads me to believe that we have an interop issue in the case where someone provides a bad filter to a Subscribe() because the fault returned is undefined. Proposal: add the above text and corresponding fault to eventing. Additionally, there's another issue here. The above fault can only be generated during subscribe time. However, not all event sources will evaluate the expression at that time - some may only do so afterwards (while processing new events). Its not clear to me what should happen in this case. I'm leaning towards us changing the spec so that when this happens the Subscription terminates (unexpectedly - e.g. generate an endSubscription msg) so that the sink knows why its not receiving any notifications. But I'd like to discuss this in the group. 44728 2 bob 2011-01-25 20:56:23 +0000 remove issue contents after "Additionally"... 44992 3 bob 2011-02-01 21:33:26 +0000 resolved as proposed