Re: WS-Eventing optionality analysis

Doug, 

+1 to the analysis and the approach to addressing it.

On 1 Oct 2010, at 19:35, 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
> 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/21/2010 06:45 PM
> 
> 
> To
> "public-ws-resource-access@w3.org" <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] 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

Take care:

    Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
    Fujitsu Laboratories of Europe Limited
    Hayes Park Central
    Hayes End Road
    Hayes, Middlesex  UB4 8FE
    Reg. No. 4153469

    +44-7590-293439 (Mobile)



______________________________________________________________________
                                        
 Fujitsu Laboratories of Europe Limited
 Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
 Registered No. 4153469
 
 This e-mail and any attachments are for the sole use of addressee(s) and
 may contain information which is privileged and confidential. Unauthorised
 use or copying for disclosure is strictly prohibited. The fact that this
 e-mail has been scanned by Trendmicro Interscan does not guarantee that 
 it has not been intercepted or amended nor that it is virus-free.