RE: proposal for 7478

Got it. The only use case I can forsee is if you ask for something in units it didn't want to deal with (much like an atm doesn't
deal in 50c), and comes back and tells you so, but I can live with as requested or a fault.

 

>From Gil's proposal under SubscribeResponse   I suggest we just  remove "or greater than" fromthe following:

 

If the Subscribe request contained a wse:Expires element with a positive xs:duration value and this element occurs in the
SubscribeResponse, it  MUST have a xs:duration value that is equal to ***or greater than*** the request value.

 

 

 

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: 17 September 2009 20:01
To: Martin Chapman
Cc: 'Li, Li (Li)'; public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: RE: proposal for 7478

 


The question isn't how to interpret the expires time of the SubscribeResponse - I would hope that the subscription does expire at
that time - as you suggest. 
What we're talking about here is the negotiation part of things.  The subscriber asks for an expires time and the source (for some
reason) wants to tweak that time.  The new attribute I'm suggesting (or even Gil's proposal) tells the source how its allowed to
tweak it.  If it can't live within those tweak rules then must fault it.  True, if we didn't allow this tweaking and the source
either accepted the value the subscriber passed in (or faulted) then that works just fine too.  And I can live with that - I was
just trying to accommodate those who saw value in the tweakiness :-) 

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. 




"Martin Chapman" <martin.chapman@oracle.com> 

09/17/2009 02:51 PM 


To

Doug Davis/Raleigh/IBM@IBMUS 


cc

"'Li, Li \(Li\)'" <lli5@avaya.com>, <public-ws-resource-access@w3.org>, <public-ws-resource-access-request@w3.org> 


Subject

RE: proposal for 7478

 

		




Thinking about it I don't see min or max making sense. 
If we allow a minimum, it means that the subscription will last for  at  least xsd:duration, and  until some unspecified time. 
If we allow a maximum it means that the subscription will last for at most xsd:duration, and can be terminated anywhere up to the
time. 
I can't really see any uses cases for these, so IMHO only one interpretation is required - unless renewed (or some other error
condition), this subscription will expire exactly at  xsd:duration. 
  
Martin. 
  
  
  
From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: 17 September 2009 19:23
To: Martin Chapman
Cc: 'Li, Li (Li)'; public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: RE: proposal for 7478 
  

Well, that's why I suggested an attribute to let the subscriber tell the src how to interpret the number - if they don't like it,
fault it. 

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. 


"Martin Chapman" <martin.chapman@oracle.com> 

09/17/2009 02:12 PM 

 


To

Doug Davis/Raleigh/IBM@IBMUS, "'Li, Li \(Li\)'" <lli5@avaya.com> 


cc

<public-ws-resource-access@w3.org>, <public-ws-resource-access-request@w3.org> 


Subject

RE: proposal for 7478


  

 

		





I do find it a bit strange that expires is a minimum, as usually a "timeout" is a maximum. 
The cleanest way to do this is to have a min and a max duration (both optional) and define the permutations. 
 
Martin. 
 
From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: 17 September 2009 15:15
To: Li, Li (Li)
Cc: public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: RE: proposal for 7478 
 

I think the current spec is pretty clear that there are two ways a subscription can end.  One is due to hitting the expires time and
the other is due to "some other reason".  No one, I think, will dispute that "some other reason" will always be possible. However,
the expires time is all about the normal termination of a subscription and that needs to be very well understood and agreed to.
Think of it this way, a normal expires will NOT generate a SubscriptionEnd message, while "some other reason" will (assuming an
EndTo is provided).  The expires time negotiation is all about the times when the SubscriptionEnd message is not involved.  These
two situations are not the same as you are implying - they have very different behavior - and (Gil should like this) the state
tables should show this difference.  :-) 

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. 


"Li, Li (Li)" <lli5@avaya.com> 

09/17/2009 10:06 AM 

  

 


To

Doug Davis/Raleigh/IBM@IBMUS 


cc

<public-ws-resource-access@w3.org>, <public-ws-resource-access-request@w3.org> 


Subject

RE: proposal for 7478



  

  

 

		





Doug, 

I will focus on my response only to your part 2) as my previous email did. 

What concerns me is the semantics of "minimum" expiry time. If a subscriber asks for an expiry time 1 hour and tags it as minimum,
can the event source terminate the subscription before 1 hour? According to current spec, it can. And this is correct, because no
event source can predict the future and guarantee that the subscription will last for 1 hour. Therefore, a subscription with a
minimum 1 hour expiry is the same as a subscription with a "random" 1 hour expiry (one created without the minimum tag). Since there
is no difference in actual lifetime between two subscriptions, adding such a tag has no consequence but creates confusions for the
subscribers. 

Thanks, 

Li Li   



  

  _____  




From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Wednesday, September 16, 2009 11:52 AM
To: Li, Li (Li)
Cc: public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: 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