- From: Gilbert Pilz <gilbert.pilz@oracle.com>
- Date: Wed, 30 Sep 2009 13:09:15 +0100
- To: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
- CC: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <4AC34A6B.7050808@oracle.com>
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>
> [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".
>
Received on Wednesday, 30 September 2009 12:09:59 UTC