Re: proposal for 7478

Li wrote:
...
> 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. 

this "hope" part is what worries me. W/o a clear guarantee that the 
subscription
can be renewed then the subscriber is taking a large gamble.  It seems to 
me that
in order to ensure we have a properly interoperable spec we need to be 
very
clear about what both sides expect and want.  Gil's proposal does this but
you are correct that it assumes the subscriber only cares about the 
minimum duration.
You point out that a subscriber might really be ok with the uncertainty 
around being able to renew (the 'hope' part) - but if so then it needs to
tell the source this bit of information.

To me there are two parts of this:
1 - we need to make sure that the source advertises what it supports by
using policy.  This means that if we keep duration and dateTime then there 
is
no interop problem as long as the source tells people which it supports.

2 - we need to make sure that the subscriber tells the source what it 
expects w.r.t. the new subscription.  This means that when it asks for an
expires time it needs to not only tell it the duration/dateTime, but it
should also indicate whether this is an upper limit or a lower limit, or
even just a suggestion.  Perhaps a new attribute on the Expires element to 

indicate this would do it.  W/o this flag I don't think we can get the
level of interop we want by sticking with the current "random" expires 
time
approach.

thanks,
-Doug