Re: Support WS-Management's persistent subscriptions

The WS-RA WG reviewed your issue on "Eventing: Support WS-Management's 
persistent subscriptions" [1] on May 11th [2] and 12th [3] 2010, during 
its face to face meeting. After discussion, the WG agreed to close this 
issue with minor changes to the WS-Eventing specification. The following 
points were made:

   1. Persistence is a difficult topic and there are a number of issues
      that need to be addressed. For example, if a device with
      persistent subscriptions were power cycled, how should any events
      that occurred while the device as powered off be handled?
   2. We do not understand why an event source which is capable of
      persisting its subscriptions would not persist all of its
      subscriptions.
   3. We see this as a quality of service concern, and after due
      consideration, we have decided that ways to accommodate such
      concerns are domain specific and outside the scope of the WS-RA work.
   4. These kind of quality of service concerns should be dealt with in
      an implementation or domain specific manner.  For example, a
      management workstation could be able to determine the kind of
      event sources it is dealing with, and have a table in its own
      state to know whether each event source supports persistence of
      its subscriptions.

However, our discussions made us realize that the spec needs a 
clarification regarding the possibility of an event source / subscription
manager going down before it can send a subscription End message to an 
EndTo EPR. Consequently we agreed to make the following changes to the 
WS-Eventing specification:

    * Add “, if possible.” to the end of the first paragraph of 4.5
      Subscription End.
    * Add the following to end of 2nd para in section 4:

    “via a SubscriptionEnd message if an EndTo was present in the
    Subscribe message.”

Please indicate via an email response to the WS-RA public comment list 
[4] as to whether this resolution of your issue is satisfactory.

[1]http://www.w3.org/Bugs/Public/show_bug.cgi?id=9613

[2]http://www.w3.org/2002/ws/ra/10/05/2010-05-11.html

[3]http://www.w3.org/2002/ws/ra/10/05/2010-05-12.html

[4]mailto:public-ws-resource-access-comments@w3.org