RE: proposal for 7478

Here are some pros and cons of the existing and newly suggested approaches.

Existing approach:


·       Pros

o   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

o   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

o   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.

·       Pros

o   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.

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?

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".