Re: combined proposal for 7586, 7588, and 7828

Upon receiving a request that contains specific time values, an Event 
Source or Subscription Manager that does not support such values types 
MUST fail the request and generate a wse:UnsupportedExpirationType fault.

I think the above needs the "types" word otherwise it could be 
interpretted as the service not liking the specific value rather than the 
xs:DateTime type.

Specific time values that lack a time zone will be interpreted in the 
local time zone of the Event Source or Subscription Manager.

Rather than "Event Source or Subscription Manager", I think "receiver" 
might be more appropriate.

These would apply to WS-Enum too, right?

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.



Gilbert Pilz <gilbert.pilz@oracle.com> 
Sent by: public-ws-resource-access-request@w3.org
10/19/2009 04:12 PM

To
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
cc

Subject
combined proposal for 7586, 7588, and 7828






Among other things, this proposal discharges my obligations under 
ACTION-113.
    - gp
Add the following after the second paragraph of 
[Body]/wse:Subscribe/wse:Expires and before 
[Body]/wse:Subscribe/wse:Expires@min. 
The value of the wse:Expires element as well as those of its min and max 
attributes MAY be either a duration (xs:duration) or a specific time (
xs:dateTime). Event Sources and Subscription Managers MUST accept duration 
values and MAY accept specific time values. Upon receiving a request that 
contains specific time values, an Event Source or Subscription Manager 
that does not support such values MUST fail the request and generate a 
wse:UnsupportedExpirationType fault.

The value types in a wse:Expires element MAY differ among the element and 
its attributes. For example, the element value may be a duration while the 
max attribute may be a specific time. Regardless of the value types, it 
must be true that wse:Expires/@min <= wse:Expires <= wse:Expires/@max as 
interpreted by the Event Source or Subscription manager at the time the 
wse:Subscribe request is processed. If this is not true, the request MUST 
fail and the receiver MUST generate a wse:InvalidExpirationTime fault.

If a Subscriber chooses to use specific time values in a request, it is 
RECOMMENDED that these values include a time zone component. Specific time 
values that lack a time zone will be interpreted in the local time zone of 
the Event Source or Subscription Manager.
Make the following changes to the description of wse:Granted Expires

[Body]/wse:SubscribeResponse/wse:GrantedExpires
The expiration time assigned by the eEvent sSource. The expiration time 
MAY be either an absolutespecific time or a duration but SHOULDMUST be of 
the same type as the requested expiration (if any)wse:Expires element of 
the corresponding request. If the corresponding requestion did not contain 
a wse:Expires element, this element MUST be a duration (xs:duration). 

When expressed as a duration, the wse:GrantedExpires element designates a 
time interval that began at the moment the Subscription is created. 
Although this specification cannot dictate when, during the processing of 
a Subscribe request, a Subscription is created, the Event Source MUST 
start the expiration interval at or before it transmits the 
wse:SubscribeResponse message.

If this element does not appear, then the subscription will not expire. 
That is, the subscription has an indefinite lifetime. It MAY be terminated 
by the subscriber using an Unsubscribe request, or it MAY be terminated by 
the event source at any time for reasons such as connection termination, 
resource constraints, or system shut-down.