W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > September 2009

RE: proposal for 7478

From: Li, Li (Li) <lli5@avaya.com>
Date: Thu, 17 Sep 2009 10:06:25 -0400
Message-ID: <7DC6C0F0E8D7C74FB4E1E73CC371280A0120B52F@300813ANEX2.global.avaya.com>
To: "Doug Davis" <dug@us.ibm.com>
Cc: <public-ws-resource-access@w3.org>, <public-ws-resource-access-request@w3.org>


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


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. 


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;
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
> create such subscription in the first place. While this may be the
> in some situations, I'm not sure WS-E should enforce this assumption
> all situations. In some situations, a subscriber may want to accept a
> subscription with a shorter expiration, with the hope that it can
> it later on when the event source is less loaded. 

this "hope" part is what worries me. W/o a clear guarantee that the
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
clear about what both sides expect and want.  Gil's proposal does this
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
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
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
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

Received on Thursday, 17 September 2009 14:07:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:52 UTC