This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 4.3 GetStatus describes what to do if a subscription is valid and not expired. However it makes no mention of what to do otherwise. Proposal: Add two new faults to section 6. 6.13 InvalidSubscriotion This fault is generated when a request specifies a subscription that is not valid [Code] s12:Sender [Subcode] wse:InvalidSubscription [Reason] The subscription is not valid [Detail] none 6.14 SubbscriotionExpired This fault is generated when a request specifies a subscription that has expired [Code] s12:Sender [Subcode] wse:SubscriptionExpired [Reason] The subscription has expired [Detail] none
Latest proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0066.html.
Created attachment 769 [details] proposal for 7553/4 7553 - Add definition of subscription to the terminology section - Before that active state exists, the renew req, get_status req, unsubscribe req must fail and may generate the invalid subscription fault. - Tidy the language in get status which suggests that there is a difference between expired and invalid 7554 - Changed InvalidSubscrption to UnknownSubscription throughout - Remove SubscribeRequestInvalid, EventSourceUnableToprocess,UnableToRenew, InvalidMessage and references to them. -Should make it clear where to put the retry in the generic fault - i.e. that it can be used in the detail space
Created attachment 770 [details] Updated proposal based on discussions
Resolved as proposed updated with text at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Oct/0045.html