RE: proposal for 7478

Subscribe is a negotiation - either side needs to be able to reject the 
other side's demands.  Having one side ignore the other's request and then 
continue w/o faulting is not a negotiation.  I'm at a loss at to why the 
source doesn't just fault the subscribe if it can't deal with what the 
subscriber is asking for?  After all, if the subscriber is ok with 
whatever the source wants to set it to then it can omit the Expires 
element and let the source pick it.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



Ram Jeyaraman <Ram.Jeyaraman@microsoft.com> 
Sent by: public-ws-resource-access-request@w3.org
09/22/2009 09:44 AM

To
Gilbert Pilz <gilbert.pilz@oracle.com>, "public-ws-resource-access@w3.org" 
<public-ws-resource-access@w3.org>
cc

Subject
RE: proposal for 7478






The general model is that the event source should decide on the duration 
of subscription expiry. This is because the event source may have specific 
policies or limits applied to each subscription due to resource limits or 
the number of event subscribers it needs to support. The event subscriber 
cannot always assume success, meaning, it may not always get what it asks 
for, and hence it has to be coded defensively. This is generally true of 
any network based application.
 
Do you think the specification could make this clearer by anointing the 
event source as the entity empowered to make the decision about 
subscription expiry duration? And perhaps leave the expiry duration 
requested in the Subscribe request by the event subscriber as a hint?
 
This allows for resilient defensive programming on the part of the event 
subscribers against failures and results in better end user experience.
 
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 11:09 AM
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".