RE: issue 7553 (GetStatus Fault messages)

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