RE: WS-Eventing optionality analysis

Well at the moment, the vague/unclear definition is appropriate.

 

From: David Snelling [mailto:David.Snelling@UK.Fujitsu.com] 
Sent: 05 October 2010 13:11
To: Doug Davis
Cc: public-ws-resource-access@w3.org
Subject: Re: WS-Eventing optionality analysis

 

Folks,

 

I'm not sure where all this is going to end, but we at least need to remove the use of "indefinite":

 

>From Wiki:

indefinite (HYPERLINK "http://en.wiktionary.org/wiki/Appendix:Glossary#comparable"comparative more indefinite, HYPERLINK "http://en.wiktionary.org/wiki/Appendix:Glossary#comparable"superlative most indefinite)

1.     Without HYPERLINK "http://en.wiktionary.org/wiki/limit"limit; forever, or until further notice; not HYPERLINK "http://en.wiktionary.org/wiki/definite"definite.

2.     HYPERLINK "http://en.wiktionary.org/wiki/vague"Vague or HYPERLINK "http://en.wiktionary.org/wiki/unclear"unclear.

3.     HYPERLINK "http://en.wiktionary.org/wiki/undecided"Undecided or HYPERLINK "http://en.wiktionary.org/wiki/uncertain"uncertain.

4.     (HYPERLINK "http://en.wiktionary.org/wiki/mathematics"mathematics) An HYPERLINK "http://en.wiktionary.org/wiki/integral"integral without specified limits.

 

>From Oxford Concise:

 

indefinite - adj.

Not clearly expressed or defined; vague.

> lasting for an unknown or unstated length of time.

 

>From Doug's Book of Spec Words:

indefinite - adj.

"dunno".

 

 

 

On 5 Oct 2010, at 02:03, Doug Davis wrote:






Gilbert Pilz <HYPERLINK "mailto:gilbert.pilz@oracle.com"gilbert.pilz@oracle.com> wrote on 10/04/2010 07:06:25 PM:
> 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.

Do you purposely say "automatically cleaned up" in one spot and 
"automatically deleted" in another?  I'm just curious if they 
mean the same thing or not.  To me they do so I'll assume they do 
to you too. 

To me you can't separate these two as part of the protocol.  W/o the 
"automatic cleanup" due to a timeout feature, you have no need for the 
Expires element at all.  Said, another way, if Subscriptions were never 
"automatically cleaned-up" due to time, and people had to call Unsubscribe, 
there wouldn't be the need for this negotiation at all. 

> 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. 

The only reason to not communicate this information is if it doesn't 
matter.  But knowing when a Subscription will be "automatically 
cleaned-up" could be vital to a subscriber otherwise they'll never 
know when to call Renew.   

Your first sentence is very confusing to me.  If we accept the notion 
that Expires in some form needs to remain (which I think everyone will 
agree to), then how can a subscriber not want/need to know what the 
resource management strategy is?  At least w.r.t. this notion of 
"automatic cleanup" due to time.  That's really all Expires is about.   
Remove the desire to explain _when_ this "automatic cleanup" will happen 
and you remove the need for Expires.  Unless you don't consider 
"automatic cleanup" due to tie to be part of the "resource management strategy". 
(I discuss this "part of" notion a bit later on) 

> 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.

Aside from some of our private IMs, I've never heard anyone refer to it 
as "you don't know".  And "never" and "a really, really long time" are, for 
our purposes, the same thing.  If there are words in the spec to imply 
that PT0S/indefinite means "dunno" then we need to fix that because that 
level of uncertainy is asking for an interop problem.  Can you show me 
where in the spec "dunno" might be implied?  I find text like this: 
  If this element does not appear, then the subscription will not 
  expire. That is, the subscription has an indefinite lifetime. Likewise, 
  a value of PT0S indicates that the subscription will not expire. 
Which is pretty clear to me that its not "dunno". 

> 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".

This is mixing topics.  While a Subscription Manager may choose to 
have this kind of resource management code, this is separate from the 
"automatic cleanup" code that is tied to the Expires element.  And 
it would be a mistake to call this kind of cleaning up "subscription 
expiring" - at least per the current spec's use of the term.  Today, 
the Expires element and the notion of "expiry" are all based on time. 
Yes there may be other factors when determining when to "automatically 
cleanup" a subscription, but those are out of scope of the spec and 
the expiry feature (and therefore the Expires element). 

It seems to me that the real issue coming from this "low water mark" 
type of example is whether or not it triggers the EndTo processing, 
not how its related to Expires/expiry/timeout.  Think of it this way... 
there are potentially many ways a Subscription could be deleted. 
Unsubscribe and "expiry" are just two of them.  Each of these are 
well defined in terms of what the protocol elements mean w.r.t. 
this part of the resource mgmt code.  This doesn't mean there couldn't 
be other aspects of the resource mgmt code - it just means we're not 
touching on them in the spec.  Section 4 of the spec include this: 
  In addition, the Event Source/Subscription Manager MAY cancel a 
  subscription at any time, as necessary. 
I think your "low water mark" example falls into that category. I 
just don't know if it is considered "unexpectedly" and should 
trigger the EndTo processing - or not.  Perhaps the spec needs to 
clear that part up?  I'm leaning towards saying it should trigger 
it since its deleting the Subscription for reasons that are not 
covered by the spec, but if some extension defines it in such a way 
as to make this trigger "expected" to a Subscriber then we're back 
to not triggering EndTo. Sigh. 

> 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". 

To me it already means this and I'm still not clear on where in the 
spec it implies anything else. 

> 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'm not following this.  The presence or absence of the Expires element 
has no impact on whether there is an agreement around expiration. 
Per the spec today, the absence of the Expires element implies PT0S. 
  If this element is not present, the implied default expiration time 
  is indefinite. A value of PT0S indicates a request for an indefinite 
  expiration time. 
This means that it has the same semantics as Expires+PT0S.  While this 
does mean that there are two ways of saying the same thing, I don't 
think this it introduces any confusion around the expiry feature. 
We can remove the optionality of the Expires element if that helps, but 
to me it was always just a handy short-hand notation. 

Likewise, we have similar text for GrantedExpires.  Its absence is 
equivalent to its presence+PT0S. 
  If this element does not appear, then the subscription will not 
  expire. That is, the subscription has an indefinite lifetime. Likewise, 
  a value of PT0S indicates that the subscription will not expire. 

It may be confusing to some people that the text we use in each of 
these cases is slightly different: 
  will not expire 
  indefinite lifetime 
  indefinite expiration time 
  expiration time is indefinite 
and we can be more consistent if that helps. 

> 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.

I'm not in favor of introducing the notion of a subscriber having 
"no interest in whether/if the subscription will be automatically 
deleted".  Back in our MEX discussions we argued to remove the "whateva" 
dialect - I'm not in favor of adding a "whateva" Expires time in 
WS-Eventing. :-)   In this case, as silly as it may sound, someone 
can choose to make all "whateva" subscriptions exactly 1 second long 
and be spec compliant.  I have no idea what Subscriber would ever 
actually ask for this kind of randomness.  As you say later on, 
if they really don't have a preferred timeout then they can use
@BestEffort with some Expires time. 

> 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. 

Now you're introducing quite a bit of ambiguity.  You've made PT0S mean 
"don't care" and "live forever".  You've also introduced this notion 
of "wishing to share" - this should never be an option.  Short hand 
notations is one thing - but saying "dunno" is something very different and 
not something we have in the spec today and I'm not infavor of adding it. 

> GrantedExpires MUST NOT use the value PT0S, as 
> that doesn't tell the subscriber anything useful. 

I disagree that GrantedExpires/PT0S isn't useful.  Its very clear that 
the Suscription will not expire.  This says nothing about other 
subscription mgmt logic - it just touches on the timeout part of it. 

> 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.

Disagree with this too.  We're asking for an interop problem if 
the two sides are not clear on when a subscription will be deleted 
due to this timeout/expiry logic.  Even if its to say "it won't be". 

Overall I disagree that anything in the spec today introduces the 
concept of not caring about this timeout stuff, or not negotiating it. 
And I think it would be a mistake to introduce it now. Even missing 
elements that imply "never expire" are still negotiating are 
communicating the agreed to values of the timeout. 

It would really help me if we could back this discussion up and 
you could point out the parts of the spec that are unclear or 
introduce the ambiguity you're concerned about.  I don't see 
where it says "no Expires", or PT0S, means "dunno".   

As I said above, if the terms we use in some spots need to be 
tweaked then we should do so - but regardless of the wording 
we're using I think the intent was that the absence of the 
Expires/GrantedExpires elements (and PT0S) means "will not be 
deleted due to time". 

-Doug 
______________________________________________________________________
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.