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.

remove issue contents after "Additionally"...

resolved as proposed