Re: proposal for 7478

Comments inline . . .

On 9/30/2009 2:44 PM, Ram Jeyaraman wrote:
>
> In general we notice that in such complex (unmanaged) environments, 
> the event subscribers are coded defensively, since there are no 
> guarantees. For example, a mobile client (laptop) moving from one 
> location to another and attempting to connect to printers available in 
> an office building. In such situations, event subscribers typically 
> tend to use the least common denominator approach of requesting for a 
> desired expiration time and yet be prepared to live with what is 
> granted (assuming if it is reasonable of course). The event sources in 
> such environments generally make a best attempt to grant the expiry 
> time that is requested unless there are good enough reasons such as 
> caching policies, running against resource limits, etc. In such 
> situations, the event subscriber providing a desired expiry time is 
> useful information for the event source to pick the best possible 
> expiry time to offer the event subscriber. It is my opinion that the 
> protocol should allow for that functionality.
>
<gp>I don't see how this is any different from simply requesting a 
Subscription with "whatever expiration" the Event Source sees free to 
assign. As a Subscriber I have no idea what sort of caching policies, 
resource limits, etc. the Event Source might be dealing with so why 
worry about providing a "hint" that the Event Source is under no 
obligation to pay any attention to? If you really want to code 
defensively, just ask for (via the absence of the Expiration element) 
and deal with whatever expiration the Event Source gives you.</gp>
>
> In more controlled (managed) environments with better guarantees or 
> pre-established policies, event subscribers may want to take advantage 
> of that fact, and be configured to request for well-known minimum 
> amount of expiry time. In the current model, the event subscriber does 
> this by asking for a desired expiry time and the event source would 
> likely grant the requested time since it’s behavior is predictable. In 
> spite of the controlled environment, if it turns out that the event 
> subscriber does not receive the requested minimum expiry time, it can 
> unsubscribe.
>
<gp>"Likely to grant the requested time" doesn't cover the use case I am 
talking about. If the Subscriber/Event Sink were able to deal with 
"likely" expirations, it would just ask (again) for a Subscription with 
"whatever expiration" and deal with that. What is *needed* is a way to 
say "I need a Subscription with this specific expiration time and, if 
you can't give me that, I don't want the Subscription at all."</gp>
>
> If the specification were to clarify that event sources must make a 
> best attempt to grant the requested expiry time, would it work for you?
>
<gp>Absolutely not; "best attempt" is an untestable concept.</gp>
>
> In spite of the suggested clarification above, if you still feel 
> strongly about providing a mechanism to explicitly ask for a minimum 
> expiry time as part the request, perhaps we can resolve this issue by 
> using the approach suggested by Doug earlier. Here is a concrete 
> version of that proposal [1]. That proposal [1] would address both the 
> use cases (unmanaged and managed).
>
<gp>No disrespect intended, but Doug's proposal seems overly complicated 
to me. The whole "hint" thing seems particularly useless. As an 
Subscriber/Event Sink am I either capable of adjusting to the expiration 
that the Event Source assigned or I am not. If I am, it doesn't really 
make much difference, from a programming perspective, whether or not 
that expiration is or isn't "close" to my "hint".

If you really can't live with the idea of the Subscriber/Event Sink 
constraining the Subscribe request, perhaps we could simply remove the 
Expiration element from the Subscribe request and simply state that 
*all* Subscribers must simply deal with whatever the Event Source 
decides upon.</gp>

- gp
>
>  
>
> Thanks.
>
>  
>
> [1] Concrete version of earlier proposal from Doug
>
>  
>
> Introduce an attribute that indicates whether the specified expiry 
> time is a hint or a minimum required time.
>
>  
>
> <Expires 
> preference="http://www.w3.org/2009/02/ws-evt/expiry/AtLeast">P1Y2M3DT10H30M12.3S</Expires> 
> indicates that the specified expiry time must at least be granted.
>
>  
>
> <Expires 
> preference="http://www.w3.org/2009/02/ws-evt/expiry/Hint">P1Y2M3DT10H30M12.3S</Expires> 
> indicates that the specified expiry time is a hint and the event 
> source is free to provide more of, less of, or exactly the requested 
> time. This is also the default value if the attribute is not specified.
>
>  
>
> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> *Sent:* Wednesday, September 30, 2009 1:09 PM
> *To:* Ram Jeyaraman
> *Cc:* public-ws-resource-access@w3.org
> *Subject:* Re: proposal for 7478
>
>  
>
> Such a constrained device probably wouldn't work correctly in a 
> complex environment in which there was no expectation that any of the 
> Event Sources of interest could support the desired expiration time, 
> but that's not a valid constraint for this use case.
>
> - gp
>
> On 9/30/2009 12:10 PM, Ram Jeyaraman wrote:
>
> The use case for minimum expiry time's is an Event Sink on a 
> constrained device that seeks to optimize the number of Subscriptions 
> that it can support. If you imagine such an Event Sink attempting to 
> support hundreds of Subscriptions it is clear that, if each 
> Subscription requires the Sink to renew every 30 seconds, most of the 
> device's bandwidth will be taken up in issuing and processing 
> Renew/RenewResponse messages
>
>  
>
> What would such a constrained device do when it lives in a complex 
> environment where there are no prior controls or knowledge of event 
> sources in that environment? Specifically, what would it do when it 
> does not find any event source that is willing to offer the requested 
> expiry time?
>
>  
>
> *From:* public-ws-resource-access-request@w3.org 
> <mailto:public-ws-resource-access-request@w3.org> 
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of *Ram 
> Jeyaraman
> *Sent:* Wednesday, September 30, 2009 11:40 AM
> *To:* Gilbert Pilz
> *Cc:* public-ws-resource-access@w3.org 
> <mailto:public-ws-resource-access@w3.org>
> *Subject:* RE: proposal for 7478
>
>  
>
> <gp>This simply isn't true. A Subscriber can always choose to send a 
> Subscribe message without an Expires element. To quote the proposal:
>
> A Subscriber MAY indicate that it is willing to accept a Subscription 
> with any expiration time by omitting this element from the Subscribe 
> request.
>
> </gp>
>
>  
>
> Indeed. I was incorrect in my characterization about the event 
> subscriber being rigid in the newly proposed approach. Thanks for the 
> correction.
>
>  
>
> However, unless I am misinterpreting the proposal – it does NOT 
> provide a way for the event subscriber to provide a hint to the event 
> source about how much expiry time it desires. This is useful 
> information that will help the event source decide on how much expiry 
> time to grant. This is because the granted expiry time is a function 
> of the requested time and what could be reasonably granted by the 
> event source in real-time.
>
>  
>
> Thanks.
>
>  
>
> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> *Sent:* Wednesday, September 30, 2009 9:52 AM
> *To:* Ram Jeyaraman
> *Cc:* public-ws-resource-access@w3.org 
> <mailto:public-ws-resource-access@w3.org>
> *Subject:* Re: proposal for 7478
>
>  
>
> Comments inline . . .
>
> On 9/30/2009 1:26 AM, Ram Jeyaraman wrote:
>
> Here are some pros and cons of the existing and newly suggested 
> approaches.
>
>  
>
> Existing approach:
>
>  
>
> Pros
>
> Allows for building event subscribers in a complex environment where 
> the quality of service or capabilities of the event source are not 
> known /a priori/. That is, the event subscriber is adaptive and can 
> survive in complex environments where there is no control over or 
> knowledge of what the event source can offer in real-time.
>
> Cons
>
> The event subscriber does not receive the requested expiry time and it 
> cannot live with a shorter expiry time, it would need to unsubscribe. 
> This is not a functional issue but incurs an extra message.
>
>  
>
> Newly suggested approach:
>
>  
>
> Cons
>
> This does not adequately support the non-managed use case where the 
> event subscriber does not know about the quality of service or 
> capabilities of the event source /a priori/. This has the side-effect 
> of creating event subscribers that are very rigid and demanding in 
> their behavior.
>
> <gp>This simply isn't true. A Subscriber can always choose to send a 
> Subscribe message without an Expires element. To quote the proposal:
>
> A Subscriber MAY indicate that it is willing to accept a Subscription 
> with any expiration time by omitting this element from the Subscribe 
> request.
>
> </gp>
>
> Pros
>
> The subscription request fails-fast, that is, it is rejected when the 
> requested expiry time cannot be granted. This is an optimization. This 
> means that the event subscriber need not have to unsubscribe if it 
> decides not to keep the offered subscription with a less than 
> requested expiry time.
>
>  
>
> Observations:
>
>  
>
> The proposed new approach while it optimizes for the case where the 
> event subscriber does not want to keep a subscription with a 
> lesser-than-requested expiry time, it takes away the adaptability of 
> the event subscribers to complex environments.
>
> <gp>In the proposal for 7478, the Subscriber is allowed three choices: 
> (1) I don't care what the expiration is, (2) I would like a specific 
> expiration period, (3) I would like a Subscription that never expires. 
> Since this provides more flexibility than the Member Submission, I 
> fail to see how this "takes away" adaptability.</gp>
>
>  
>
> Question:
>
>  
>
> It is not clear to me why an event subscriber must always want at 
> least the minimum request expiry time to be granted. What is wrong 
> with sending an unsubscribe if the granted expiry time is not 
> sufficient or renewing to ask for more time? What is the need to 
> require such exact expiry times?
>
> <gp>Again, it's not true the Subscriber "must always want at at least 
> the minimum request expiry time to be granted". The fact that you 
> think this is the case leads me to believe that you really don't 
> understand the proposal. The proposal *allows* the Subscriber to ask 
> for a minimum request expiry time, but that is only one of the three 
> options outlined above.
>
> The use case for minimum expiry time's is an Event Sink on a 
> constrained device that seeks to optimize the number of Subscriptions 
> that it can support. If you imagine such an Event Sink attempting to 
> support hundreds of Subscriptions it is clear that, if each 
> Subscription requires the Sink to renew every 30 seconds, most of the 
> device's bandwidth will be taken up in issuing and processing 
> Renew/RenewResponse messages.</gp>
>
>  
>
> While I appreciate the thought and effort behind the proposed new 
> approach, my preference is to retain the existing approach.
>
>  
>
> On the other hand, if there is a compelling use case for optimizing 
> the protocol for the case where the event source does not want to keep 
> a subscription with less-than-requested expiry time, I am willing to 
> consider the approach that Doug suggested earlier:
>
>  
>
> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0047.html 
>
>
>  
>
> 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.
>
>  
>
> This allows the event subscriber to be adaptive while simultaneously 
> providing the opportunity to fail-fast a subscription.
>
>  
>
> Thanks.
>
>  
>
> *From:* public-ws-resource-access-request@w3.org 
> <mailto:public-ws-resource-access-request@w3.org> 
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of 
> *Gilbert Pilz
> *Sent:* Friday, September 11, 2009 7:09 PM
> *To:* public-ws-resource-access@w3.org 
> <mailto:public-ws-resource-access@w3.org>
> *Subject:* proposal for 7478
>
>  
>
> Notes:
>
> 1.) We've removed the use of xs:dateTime for specifying expiration 
> time. The reason for this is that the submission spec allowed Event 
> Sources that didn't have a wall clock to fail on the use of 
> xs:dateTime. This creates an interoperability problem because a 
> Subscriber has no way of knowing whether or not an Event Source can or 
> can't support xs:dateTime. An interoperable Subscriber must always be 
> capable of falling back to the use of xs:duration, so we might as well 
> just use that. Furthermore, some members of the WG have indicated that 
> they would prefer xs:duration over xs:dateTime because the former was 
> simpler to deal with (one example cited the problems of xs:dateTime's 
> that lack any timezone designation, etc.) This simplifies the parsing 
> for wse:Expires since it is now just a restriction of a xs:duration 
> and no longer a xs:union. The InvalidExpirationTime fault is no longer 
> necessary and has been removed.
>
> 2.) The existing text for /wse:SubscribeResponse/wse:Expires implies 
> that this element is optional ("if this element does not appear") 
> whereas the schema indicated that this element is mandatory. This 
> proposal changes the schema to indicate that Expires is an optional 
> element for SubscribeResponse.
>
> 3.) The presence/absence of wse:Expires has a different meaning for 
> wse:Subscribe then in does for wse:SubscribeResponse. For 
> wse:Subscribe it means "I don't care what expiration value you give 
> me". For wse:SubscribeResponse it means "the newly created 
> Subscription does not expire". Although this may seem little weird at 
> first, it is consistent with the negotiation model.
>
> 4.) This proposal includes the appropriate changes to Renew, 
> RenewResponse, GetStatusResponse as well as changes to examples.
>
> - gp
>
> ------------------------------------------------------------------------
>
> Change the outline of Subscribe to the following:
>
> *[Action]*
>   http://www.w3.org/2009/02/ws-evt/Subscribe
>
> *[Body]*
>   <wse:Subscribe ...>
>     <wse:EndTo> endpoint-reference </wse:EndTo> ?
>     <wse:Delivery ...> xs:any* </wse:Delivery>
>     <wse:Format Name="xs:anyURI"? > xs:any* </wse:Format> ?
>     <wse:Expires> xs:duration </wse:Expires> ?
>     <wse:Filter Dialect="xs:anyURI"? ...> xs:any* </wse:Filter> ?
>     xs:any*
>   </wse:Subscribe>
>
> Change the description of /wse:Subscribe/wse:Expires to the following:
>
> *[Body]/wse:Subscribe/wse:Expires*
>
> This optional element can be used by the Subscriber to negotiate the 
> expiration time of the requested Subscription.
>
> A Subscriber MAY indicate that it is willing to accept a Subscription 
> with any expiration time by omitting this element from the Subscribe 
> request.
>
> A Subscriber MAY request a Subscription with a minimum expiration time 
> by including this element in the Subscribe request with a positive 
> xs:duration value that specifies the minimum time between the 
> Subscription's creation time (based on the Event Source's clock) and 
> the time of its expiration. If the Event Source creates a Subscription 
> from such a Subscribe request, the expiration time of the Subscription 
> MUST be equal to or greater than the time indicated by the value of 
> this element, or the Subscription MUST NOT expire. If the Event Source 
> does not honor the requested minimum expiration time, the request MUST 
> fail, and the Event Source MUST generate a wse:ExpirationTimeExceeded 
> fault.
>
> A Subscriber MAY request a Subscription that never expires by 
> including this element with an xs:duration value of zero 
> ("P0Y0M0DT0H0M0S"). If the Event Source creates a Subscription from 
> such a Subscribe request, the Subscription MUST NOT expire. If the 
> Event Source does not honor a request for a Subscription that does not 
> expire, the request MUST fail, and the Event Source MUST generate a 
> wse:ExpirationTimeExceeded fault.
>
> ------------------------------------------------------------------------
>
> Change the outline of SubscribeResponse to the following:
>
> [Action]
>   http://www.w3.org/2009/02/ws-evt/SubscribeResponse
>
> [Body]
>   <wse:SubscribeResponse ...>
>     <wse:SubscriptionManager>
>       wsa:EndpointReferenceType
>     </wse:SubscriptionManager>
>     <wse:Expires> xs:duration </wse:Expires> ?
>     xs:any*
>   </wse:SubscribeResponse>
>
> Change the description of /wse:SubscribeResponse/wse:Expires to the 
> following:
>
> *[Body]/wse:SubscribeResponse/wse:Expires*
>
> This optional element is used to communicate the assigned expiration 
> time of the newly created Subscription. The absence of this element in 
> a SubscribeResponse indicates that the Subscription will not expire; 
> i.e. the Subscription has an indefinite lifetime.
>
> If the Subscribe request did not contain a wse:Expires element and 
> this element occurs in the SubscribeResponse, it MUST have a positive 
> xs:duration value.
>
> 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.
>
> If the Subscribe request contained a wse:Expires element wtih the a 
> zero value ("P0Y0M0DT0H0M0S"), this element MUST NOT appear in the 
> SubscribeResponse.
>
> Note that, regardless of its expiration time, a Subscription MAY be 
> terminated by the Event Source at any time for reasons such as 
> resource constraints, or system shut-down.
>
> ------------------------------------------------------------------------
>
> Fix Example 4-1 and Example 4-2 to use an xs:duration value for their 
> respective wse:Expires elements making sure that the above 
> restrictions are adhered to.
>
> ------------------------------------------------------------------------
>
> Change the outline of Renew to the following:
>
> [Action]
>   http://www.w3.org/2009/02/ws-evt/Renew
>
> [Body]
>   <wse:Renew ...>
>     <wse:Expires> xs:duration </wse:Expires> ?
>     xs:any*
>   </wse:Renew>
>
> ------------------------------------------------------------------------
>
> Change the outline of RenewResponse to the following:
>
> [Action]
>   http://www.w3.org/2009/02/ws-evt/RenewResponse
>
> [Body]
>   <wse:RenewResponse ...>
>     <wse:Expires> xs:duration </wse:Expires> ?
>     xs:any*
>   </wse:RenewResponse>
>
> Change the description of /wse:RenewResponse/wse:Expires to the following:
>
> This optional element is used to communicate the assigned expiration 
> time of the newly renewed Subscription. The start of this duration is 
> the time when the Subscription Manager started processing the Renew 
> request.
>
> ------------------------------------------------------------------------
>
> Fix Example 4-3 and Example 4-4 to use an xs:duration value for their 
> respective wse:Expires elements.
>
> ------------------------------------------------------------------------
>
> Change the outline of GetStatusResponse to the following:
>
> [Action]
>   http://www.w3.org/2009/02/ws-evt/GetStatusResponse
>
> [Body]
>   <wse:GetStatusResponse ...>
>     <wse:Expires> xs:duration </wse:Expires> ?
>     xs:any*
>   </wse:GetStatusResponse>
>
> ------------------------------------------------------------------------
>
> Fix Example 4-6 to use an xs:duration value for the wse:Expires element.
>
> ------------------------------------------------------------------------
>
> Change the schema definition of the "ExpirationType" to the following:
>
>   <xs:simpleType name="ExpirationType">
>     <xs:restriction base="xs:duration">
>       <xs:minInclusive value="P0Y0M0DT0H0M0S" />
>     </xs:restriction>
>   </xs:simpleType>
>
> Change the definition of SubscribeResponse to:
>
>   <xs:element name="SubscribeResponse">
>     <xs:complexType>
>       <xs:sequence>
>         <xs:element name="SubscriptionManager"
>                     type="wsa:EndpointReferenceType" />
>         <xs:element name="Expires"
>                     type="tns:ExpirationType"
>                     minOccurs="0" />
>         <xs:any namespace="##other" processContents="lax"
>                 minOccurs="0" maxOccurs="unbounded" />
>       </xs:sequence>
>       <xs:anyAttribute namespace="##other" processContents="lax" />
>     </xs:complexType>
>   </xs:element>
>
> ------------------------------------------------------------------------
>
> Add the following fault to Section 6:
>
> 6.x ExpirationTimeExceeded
>
> This fault is generated when a Subscribe request specifies a minimum 
> expiration time that exceeds what the Event Source is willing to 
> support. This includes requests that use a zero xs:duration value to 
> specify an infinite expiration time.
>
> *[Code]*
>
>  
>
> s12:Sender
>
> *[Subcode]*
>
>  
>
> wse:ExpirationTimeExceeded
>
> *[Reason]*
>
>  
>
> The requested expiration time exceeds internal limits
>
> *[Code]*
>
>  
>
> /Optional xs:duration which specified the maximum expiration time 
> supported by the Event Source./
>
>  
>
> ------------------------------------------------------------------------
>
> Remove Section 6.2 "InvalidExpirationTime".
>
> Remove Section 6.3 "UnsupportedExpirationType".
>