Re: proposal for 7478

(too add to the other threads on this subject)

I think you are missing an important aspect in the proposal and that is 
that the Subscriber is provided with a greater/clearer range of 
expression with regards to expiration. The Subscriber can now say (a) "I 
don't care when/if this Subscription expires", (b) "I need a 
Subscription that never expires", (c) "I need a Subscription that, if it 
does expire, expires no sooner than X". Option (c) is a new feature. The 
member submission, effectively, only allowed for (a) or (b). True, the 
Subscriber was allowed to provide an expiration time but, since the 
Event Source was allowed to ignore it, you end up with (a) - the 
Subscriber/Event Sink had to be able to deal with whatever the Event 
Sink decided upon.

If you have a use case in which the Subscriber "may want to accept a 
Subscription with a shorter expiration, with the hope that it can renew 
it later on when the event source is less loaded", that Subscriber 
should use option (a). You don't have to use option (c) and "repeatedly 
submit subscriptions with shorter expiration in order to be accepted".

- gp

On 9/16/2009 7:19 AM, Li, Li (Li) wrote:
> This response concerns point 2) and 3) in the proposal as point 1) is in
> a separate issue and point 4) depends on 2) and 3).
>
> This proposal changes the current WS-E draft in the following ways:
>
> 1) It removes the possibility for an event source to return an
> expiration that is less/earlier than the value requested by the
> subscriber in a successful subscription;
>
> 2) It removes the following paragraph from the definition of Expires
> element in Section 4.1:
>
> If this element does not appear, then the request is for a subscription
> that will not expire. That is, the subscriber is requesting the event
> source to create a subscription with an indefinite lifetime. If the
> event source grants such a subscription, it MAY be terminated by the
> subscriber using an Unsubscribe request, or it MAY be terminated by the
> event source at any time for reasons such as connection termination,
> resource constraints, or system shut-down. 
>
> By change 1), it assumes all subscribers will never accept any
> subscriptions with a shorter expiration. Therefore, there is no need to
> create such subscription in the first place. While this may be the case
> in some situations, I'm not sure WS-E should enforce this assumption for
> all situations. In some situations, a subscriber may want to accept a
> subscription with a shorter expiration, with the hope that it can renew
> it later on when the event source is less loaded. In some cases, getting
> some notifications now is better than getting no notifications at all.
> If we remove this flexibility, a subscriber desperate for notifications
> has to repeatedly submit subscriptions with shorter expiration in order
> to be accepted. Therefore, I feel this restriction should be enforced by
> the event source implementations, instead of the spec itself. 
>
> By change 2), the proposal gives the people impression that an
> indefinite subscription cannot be terminated by the event source. 
>
> Thanks,
>
> Li Li
>
>  
>
>