Re: WS-Eventing optionality analysis

  On 10/4/2010 7:06 PM, Gilbert Pilz wrote:
> Doug,
I like Gil's proposal, however "MAY NOT" in 4) is incorrect usage, it 
needs to be "MUST NOT".

Tom
>
> I disagree with most of what you said below and almost all of that 
> disagreement stems from the meaning of the word "expire" and its 
> derivatives. In particular, I have a large negative reaction to the 
> phrase "indefinite expiration". Let me explain.
>
> I think that the problem with both the current spec and your comments 
> below is that the way the terms "expire", "expiration" etc. are used 
> is conflating two separate concepts. One of them (which you refer to 
> as the "expiry feature") concerns the resource management strategy 
> employed by the subscription manager to manage the resources 
> associated with a subscription; the idea that every subscription will 
> be automatically cleaned up a specific, known time etc. The other 
> concerns the existence (or lack thereof) of an *agreement* between the 
> subscriber and the subscription manager as to if/when the subscription 
> will be automatically deleted. This conflation of these two ideas is 
> causing problems.
>
> First, there is no reason for a subscriber to want or need to know 
> anything about the resource management strategies used by the 
> subscription manager. Any attempt to communicate this information 
> represents a hole in our abstraction of a subscription manager - a 
> hole that can only cause misunderstandings and interoperability 
> problems. For an example, consider the disconnects around the use of 
> the phrase "indefinite" and the value "PT0S". Some people seem to 
> think it means "never", others "a really, really long time" and others 
> simply "you don't know". The idea of an "indefinite expiration" is 
> both useless and dangerous.
>
> Secondly, we have to keep in mind that there are many different ways 
> to manage the resources associated with a subscription. One strategy 
> could be to simply monitor the level of various critical resources 
> and, when these reach a low water mark, start deleting subscriptions 
> on a least recently used basis. A subscription manager that implements 
> this strategy can not tell you when, or even if, it is going to 
> "expire" a subscription - whoever implemented it probably wasn't even 
> thinking in those terms. It's simply not true to say that "all 
> subscription managers implicitly support the notion of expiry".
>
> I think that, to be of any use at all, we need to narrow down the 
> definition of "expiration" to refer to "the *agreement* between the 
> subscriber and the subscription manager on when then subscription will 
> be automatically terminated". We might even want to change all 
> occurrences of the English word "expiration" to "subscription 
> expiration". This is analogous to the stock trading term "stock 
> option". In English, the word "option" means very loosely "the 
> right/ability to do something", but in context of equity trading a 
> "stock option" refers to an explicit, legally binding agreement 
> between two parties. We need the term "subscription expiration" to 
> have the same flavor.
>
> Finally, we need to reduce the number of ways that the WS-Eventing 
> protocol signals the existence (or lack thereof) of subscription 
> expiration agreement. I think the following should apply:
>
> 1. If the subscriber has no interest in whether/if the subscription 
> will be automatically deleted, it does not include the Expires element 
> in the Subscribe request. In such cases the subscription manager MUST 
> NOT include the GrantedExpires element in the SubscribeResponse. The 
> end result will always be that there is no subscription expiration. If 
> EndTo was specified, the subscription manager MUST send a 
> SubscriptionEnd message if/when it automatically deletes the message 
> since there was no way for the subscriber to know if/when this was 
> going to happen.
>
> 2. If the subscriber needs to know whether/if the subscription will be 
> automatically deleted, but doesn't wish to "bid" a particular time, it 
> includes the Expires element with a value of "PT0S". If the 
> subscription manager knows or can figure out if/when the subscription 
> will be automatically deleted, and it wishes to share this information 
> with the subscriber (i.e. it supports the negotiation of a 
> subscription expiration), it accepts the request and indicates that 
> time via the GrantedExpires element in the SubscribeResponse. 
> GrantedExpires MUST NOT use the value PT0S, as that doesn't tell the 
> subscriber anything useful. If the subscription manager either can not 
> or will not tell the subscriber when the subscription will be 
> automatically deleted (i.e. it does not support the negotiation of a 
> subscription expiration) it generates the wse:ExpiresNotSupported fault.
>
> 3. If the subscriber both needs to know whether/if the subscription 
> will be automatically deleted, and has a specific idea of when it 
> needs this to happen, it includes the Expires element with a 
> non-"PT0S" value. A @BestEffort value of 'true' shades this to mean 
> "something close to this value". If the subscription manager either 
> can not or will not tell the subscriber when the subscription will be 
> automatically deleted (i.e. it does not support the negotiation of a 
> subscription expiration) it generates the wse:ExpiresNotSupported 
> fault. If the particular value requested by the subscriber is 
> unacceptable in value or type, the subscription manager generates the 
> wse:UnsupporedExpirationValue or wse:UnsupportedExpirationType faults 
> (respectively).
>
> 4. If a subscription manager does not support the negotiation of 
> subscription expirations, it MAY NOT support the Renew operation as 
> the Renew is a no-op under these conditions.
>
> 5. If a subscription manager supports the negotiation of subscription 
> expirations, it MUST support the Renew operation and it MUST support 
> the use of both wse:Subscribe/wse:Expires and wse:Renew/wse:Expires.
>
> I think we can encode the above in the spec with a minimum of changes; 
> mostly wording changes, the removal of PT0S from the value space of 
> GrantedExpires, and the changing of Renew from mandatory to optional.
>
> ~ gp
>
> On 10/1/2010 11:35 AM, Doug Davis wrote:
>>
>> Been thinking about this and I actually think the inconsistency is 
>> some place else in the doc.  If you look at how the Subscribe 
>> operation is defined, it basically says this - w.r.t. Expires:
>> - the Expires element is optional for both the subscriber and the 
>> event source
>> - an event source is not required to support the Expires element 
>> (note, it says 'element' not the expiry feature)
>> - the absence of the Expires element means that the subscription has 
>> an indefinite expiration time
>> - an Expires element with a value of PT0S also means indefinite 
>> expiration
>>
>> Note that the absence of the Expires element doesn't mean that the 
>> Subscription Manager doesn't have to support the notion of expiry. 
>>  In fact, the spec says the exact opposite when it says that there is 
>> a default value for Expires of 'indefinite':
>>         If this element is not present, the implied default 
>> expiration time is indefinite.
>>
>> This means that Subscription Managers do in fact need to support the 
>> notion of expiry, its just that in some cases they may only support 
>> the 'indefinite' or PT0S value.  Which is fine.  But this is where 
>> the inconsistency lies.
>>
>> The spec right now, mistakenly, gives the impression that the feature 
>> of expiry is optional for the Subscription Manager by making the 
>> Expires element option for it to support.  But, this isn't true - the 
>> spec makes it clear that even w/o the presence of the Expires element 
>> the expiry feature gets a default value (PT0S) - so while the Expires 
>> element may be optional, the feature behind it is not.  If this isn't 
>> clear, think of it this way:  what is the semantic difference between 
>> a Subscribe w/o an Expires element and a Subscribe with an Expires 
>> element that has a PT0S value?  W.r.t. the expiry feature there is no 
>> difference.  This is why I believe that presence or absence of the 
>> Expires element has no relation to whether expiry itself is supported 
>> - in short because it is always supported.
>>
>> Now, in practice someone may choose to look at this and say that 
>> absence of Expires (or even Expires + PT0S) is the equivalent of not 
>> supporting expiry because it'll never expire.  And that is true from 
>> an "end results" type of perspective, but from a spec perspective 
>> these are very different things.  How someone chooses to implement a 
>> PT0S value is up to them.  Whether they set a timeout value to a very 
>> large number or whether they just never check for a timeout at all is 
>> an implementation choice.  But either way, from an on-the-wire/spec 
>> perspective they are in fact supporting Expires with a value of PT0S 
>> - as the spec says.
>>
>> So, in the end I think the inconsistency is around the notion of 
>> allowing an Event Source (or Subscription Manager) to claim that it 
>> doesn't support the Expires element - its silly to not support the 
>> element when it must support the feature behind the element.  Or said 
>> another way, its silly to allow someone to imply a value of PT0S but 
>> then fault them when they try to be explicit about it.  We should 
>> remove sentences like:
>> If the event source does not support the wse:Expires element being 
>> present in a Subscribe request message then a wse:ExpiresNotSupported 
>> fault MUST be generated.
>> And if people don't want to support anything but indefinite expiry 
>> times then they should only allow Subscribes (or Renews) with either 
>> no Expires element or an Expires element with a value of PT0S.  This 
>> is related to the issue I opened earlier today [1].  If we remove the 
>> above sentence and tweak the policy then we can remove the 
>> wse:ExpiresNotSupported fault too.
>>
>> I don't think this would change the semantics of the spec at all and 
>> would clear up any inconsistency around this point.  Its also 
>> consistent with the Member Submission too which didn't allow an Event 
>> Source to reject a Subscribe solely due to the presence of the 
>> Expires element.
>>
>> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10960
>>
>> thanks
>> -Doug
>> ______________________________________________________
>> STSM |  Standards Architect  |  IBM Software Group
>> (919) 254-6905  |  IBM 444-6905  | dug@us.ibm.com
>> The more I'm around some people, the more I like my dog.
>>
>>
>> *Gilbert Pilz <gilbert.pilz@oracle.com>*
>> Sent by: public-ws-resource-access-request@w3.org
>>
>> 09/30/2010 02:59 PM
>>
>> 	
>> To
>> 	Doug Davis/Raleigh/IBM@IBMUS
>> cc
>> 	"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
>> Subject
>> 	Re: WS-Eventing optionality analysis
>>
>>
>>
>> 	
>>
>>
>>
>>
>>
>> I don't know if this point has ever been discussed before, but it 
>> seems to me that there is an inconsistency in the optionality of 
>> elements and operations in WS-Eventing. Specifically Event 
>> Sources/Subscription Managers are not required to support 
>> subscription expiration, yet Subscription Managers are required to 
>> support the Renew operation. Since the function of the Renew 
>> operation is to update the expiration for a subscription, by 
>> definition this operation has to be a no-op for implementations that 
>> don't support any form of expiration.
>>
>> Did we have a reason for doing this, or are we just stupid?
>>
>> ~ gp
>>
>> On 9/27/2010 7:03 AM, Doug Davis wrote:
>>
>> Nice catch on the Expires issue.  Seems to me that it would be good 
>> for the spec to mandate that whatever choice the event source makes 
>> that it be consistent across all operations.  Sounds like a new 
>> issues to me.
>>
>> thanks
>> -Doug
>> ______________________________________________________
>> STSM |  Standards Architect  |  IBM Software Group
>> (919) 254-6905  |  IBM 444-6905  | _dug@us.ibm.com_ 
>> <mailto:dug@us.ibm.com>
>> The more I'm around some people, the more I like my dog.
>>
>> *Gilbert Pilz **_<gilbert.pilz@oracle.com>_* 
>> <mailto:gilbert.pilz@oracle.com>
>> Sent by: _public-ws-resource-access-request@w3.org_ 
>> <mailto:public-ws-resource-access-request@w3.org>
>>
>> 09/21/2010 06:45 PM
>>
>> 	
>> To
>> 	_"public-ws-resource-access@w3.org"_ 
>> <mailto:public-ws-resource-access@w3.org> 
>> _<public-ws-resource-access@w3.org>_ 
>> <mailto:public-ws-resource-access@w3.org>
>> cc
>> 	
>> Subject
>> 	WS-Eventing optionality analysis
>>
>>
>>
>>
>> 	
>>
>>
>>
>>
>>
>>
>> Attached is an analysis of the optionality of the various 
>> operations/messages and features in WS-Eventing. I'm not sure if this 
>> format is the best for displaying this information. I tried to color 
>> code things: black is required, blue is required for one party but 
>> not another, red is optional for both parties. 
>> Sub-elements/sub-features are scoped to the optionality of there 
>> containing element/feature. For example, event sources are required 
>> to support expiration values using xs:duration *iff* they support 
>> wse:Expires, but subscribers may elect to use xs:dateTime values - so 
>> xs:duration is blue (required for event source, optional for 
>> subscriber) scoped by a red element/feature (wse:Expires).
>>
>> If anyone has a better suggestion on how to display this info, please 
>> speak up.
>>
>> One issue that writing this analysis brought up is the granularity of 
>> options. In the case of WS-Eventing this only impacts subscription 
>> expiration, but it might impact the other spec differently. For 
>> WS-Eventing the question is, "If you are an event source that 
>> supports wse:Subscribe/wse:Expires are your subscription manager 
>> therefor required to support wse:Renew/wse:Expires?" Put another way, 
>> "Can I have a subscription manager that supports 
>> wse:Renew/wse:Expires even though my event source doesn't support 
>> wse:Subscribe/wse:Expires?"
>>
>> ~ gp[attachment "ws-eventing-optionality-analysis.odt" deleted by 
>> Doug Davis/Raleigh/IBM]


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133