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

RE: Issue 7553: Eventing - GetStatus Fault Message (action item 102) - Minor amendments to proposal

From: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
Date: Tue, 29 Sep 2009 23:31:08 +0000
To: Katy Warr <katy_warr@uk.ibm.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Message-ID: <503546C5699C1144BDEA0D0DFFE7F8810990ADA3@TK5EX14MBXC110.redmond.corp.microsoft.com>
In the situation where the subscription has either expired or ended, the subscription manager endpoint will not be available. In that case, isn't it true that an endpoint unavailable fault or such would be returned?

Thanks.

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Katy Warr
Sent: Tuesday, September 22, 2009 11:04 AM
To: public-ws-resource-access@w3.org
Subject: Fw: Issue 7553: Eventing - GetStatus Fault Message (action item 102) - Minor amendments to proposal


On further consideration, the text #4 "A subscription is not valid if it has expired." is an important definition that is not specific to the GetStatus message.  Assuming that the group agrees with this point, I suggest that we remove it from 4.3 and instead state it once only at the beginning of the document by adding a definition of the word 'Subscription' to the Terminology section.  A definition for Subscription should probably be in the terminology section anyhow.  Like this:

3.4 Terminology
"Subscription
A registration of interest in receiving Notification messages from an Event Source.  Subscriptions may be created, renewed, expired or cancelled.  A subscription that has expired or deleted is no longer valid."

Also, the text in #1:
 "If the event source is unable to perform the request because the subscription is not valid, the request MUST fail and the subscription manager MUST generate a wse:InvalidSubscription fault."
is ambiguous as it does not *prevent* the subscription manager from performing the request if the subscription is invalid.  Assuming that is what we require, I suggest this instead:
 "If the subscription is not valid, the request MUST fail and the subscription manager MUST generate a wse:InvalidSubscription fault."

----- Forwarded by Katy Warr/UK/IBM on 22/09/2009 10:31 -----
From:

Katy Warr/UK/IBM

To:

public-ws-resource-access@w3.org

Date:

17/09/2009 17:47

Subject:

Issue 7553: Eventing - GetStatus Fault Message (action item 102)


________________________________


Following discussions from Tuesday's call, here's a proposed fix for http://www.w3.org/Bugs/Public/show_bug.cgi?id=7553 action item 102 http://www.w3.org/2002/ws/ra/tracker/actions/102

1) Add text to 4.3 GetStatus:
"If the event source is unable to perform the request because the subscription is not valid, the request MUST fail and the subscription manager MUST generate a wse:InvalidSubscription fault.""

2) Add the following fault section:

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]         <wse:SubscriptionExpired>?
                       Optional.

3) Extend section 6.1 to correctly detail the subscriptionExpired element:

6.1 Fault Detail Elements
The following elements are used to convey additional information in the faults.
6.1.1 RetryAfter
/wse:RetryAfter
    This element (whose content is of type xs:unsignedLong) is a suggested minimum duration in milliseconds to wait before retransmitting the message. Omission of this element indicates that a retry is never likely to succeed.
/wse:RetryAfter/@any
    Optional extensibility attributes that do not affect processing.
6.1.2 SubscriptionExpired
/wse:SubscriptionExpired
    This empty element MAY be used by a subscription manager to indicate that it was unable  to process a request because the subscription to which the request refers has expired.
This is an optional element.  Implementations are not required to retain information about expired subscriptions.
/wse:SubscriptionExpired/@any
    Optional extensibility attributes that do not affect processing

4) The current wording in the spec implies that expired subscriptions are valid.  This contradicts the above usage of faults (where expired subscriptions are not valid).  Replace the following text in 4.3 GetStatus:
"If the subscription is valid and has not expired, the subscription manager MUST reply with a response of the following form: "
with
"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: "

________________________________


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
Received on Tuesday, 29 September 2009 23:31:47 GMT

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