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