RE: issue 7553 (GetStatus Fault messages)

Perhaps we could add an optional Detail to the InvalidSubscription fault 
in order to indicate that the subscription expired if the event source has 
retained that information?  That way we give the option to differentiate 
if the event source is capable of remembering expired subscriptions. 

As Paul says, we still need to tweak the wording so it doesn't imply that 
expired subscriptions are valid (e.g. "A subscription is not valid if it 
has expired.  If the subscription is valid, the subscription manager MUST 
reply with a response of the following form: ")

Katy




From:
Paul Nolan/UK/IBM@IBMGB
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
Date:
14/09/2009 08:50
Subject:
RE: issue 7553 (GetStatus Fault messages)




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 













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