W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > September 2009

RE: issue 7553 (GetStatus Fault messages)

From: Paul Nolan <NOLANPT@uk.ibm.com>
Date: Mon, 14 Sep 2009 08:49:47 +0100
To: Gilbert Pilz <gilbert.pilz@oracle.com>
Cc: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, public-ws-resource-access-request@w3.org
Message-ID: <OF96757821.46BC92F6-ON80257631.0028DE06-80257631.002B0360@uk.ibm.com>
Hi Gil,

It certainly does not make sense to expect an Event Source remember 
expired subscriptions. I guess I was responding to the wording on Section 
4.3 that says "If the subscription is valid and has not expired ...". So 
we are saying that expired subscriptions are also invalid so we do not 
really need to differentiate between them. I suppose we either do not need 
to mention "expired "at all or perhaps someone somewhere may want to cache 
expired subscription information as we are not preventing it.

So if we remove the proposal for fault 6.14 perhaps we should also tweak 
the wording in section 4.3?

Regards

Paul Nolan
Web Services Development
Hursley, England, 44(0) 1962 817228 (Internal 247228) 
Internet: nolanpt@uk.ibm.com



From:
Gilbert Pilz <gilbert.pilz@oracle.com>
To:
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Date:
11/09/2009 22:12
Subject:
RE: issue 7553 (GetStatus Fault messages)
Sent by:
public-ws-resource-access-request@w3.org



Paul's proposal contains the following:
Add two new faults to section 6.

6.13 InvalidSubscriotion [sic]

This fault is generated when a request specifies a subscription that is 
not
valid

. . .

6.14 SubbscriotionExpired [sic]

This fault is generated when a request specifies a subscription that has
expired

. . .

The only way an Event Source would be able to detect if a Subscription has 
expired is if it "remembers" (i.e. stores state for) Subscriptions after 
they expire. Some (most?) Event Source's may choose to simply "forget 
about" (i.e. remove all state for) expired Subscriptions. After all, there 
isn't anything useful anyone can do with an expired Subscription, and 
storing the state of every Subscription that ever existed could be quite 
burdensome. The WS-Eventing spec cannot require Event Source impls to 
"remember" expired Subscriptions.

That being the case, it is fairly apparent that a requester that sends a 
Renew, GetStatus, or Unsubscribe request for a one-valid Subscription that 
has expired may get back either an InvalidSubscription fault (if the Event 
Source forgets about expired Subscriptions) or a SubscriptionExpired fault 
(if the Event Source remembers expired Subscriptions). Since the state 
transition for both faults is exactly the same, I would like to amend the 
proposal to remove the "SubscriptionExpired" fault.

- gp







Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Received on Monday, 14 September 2009 07:50:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:18:13 GMT