Re: proposal for 7478

On Sep 30, 2009, at 6:44 AM, 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.
>
> 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.
>
> 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?

"best attempt" is a completely meaningless, non quantifiable, term.
    -jeff

>
> 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).
>
> 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 
> ] On Behalf Of Ram Jeyaraman
> Sent: Wednesday, September 30, 2009 11:40 AM
> To: Gilbert Pilz
> Cc: 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
> 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 
> ] On Behalf Of Gilbert Pilz
> Sent: Friday, September 11, 2009 7:09 PM
> To: 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".

--
Jeff Mischkinsky			          		jeff.mischkinsky@oracle.com
Director, Oracle Fusion Middleware 				+1(650)506-1975
	and Web Services Standards           			500 Oracle Parkway, M/S 2OP9
Oracle								Redwood Shores, CA 94065

Received on Wednesday, 30 September 2009 14:23:37 UTC