RE: Re: Issue 7554: Eventing - Unsubscribe Fault Message (action item 103)

> Event Source Unable To Process Fault OR Subscription Manager Unable To Process

Actually, a receiver could use the SOAP 'Receiver' fault to indicate that the message could not be processed for reasons attributable to the processing of the message rather than to the contents of the message itself!

Regards,

Asir S Vedamuthu
Microsoft Corporation

-----Original Message-----
From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Li, Li (Li)
Sent: Tuesday, September 29, 2009 3:03 PM
To: public-ws-resource-access@w3.org
Cc: Chou, Wu (Wu)
Subject: RE: Re: Issue 7554: Eventing - Unsubscribe Fault Message (action item 103)

Katy,

I have a minor problem with using EventSourceUnableToProcess as the
catch-all fault for the getstatus/renew/unsubscribe messages, as in your
proposal [1]:

Please note:  Li li added a comment to this issue here 
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7554#c1 suggesting that we

should have an UnableToXXX fault for each of Subscribe, Renew,
GetStatus, 
Unsubscribe.  Currently, Subscribe uses EventSourceUnableToProcess for 
this purpose; Renew uses UnableToRenew; Unsubscribe and GetStatus don't 
have an equivalent fault.  This proposal suggests that they all share
the 
EventSourceUnableToProcess fault to indicate a general failure to
process 
the request.

I think EventSourceUnableToProcess is ok for the subscribe message as it
is sent to the Event Source. But using it for other messages seems
inconsistent with our architecture that these other messages are sent to
the Subscription Manager, not the Event Source. Would a
SubscriptionManagerUnableToProcess be more appropriate? 

Thanks.

Li

[1]
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/00
52.html

Received on Tuesday, 29 September 2009 22:10:26 UTC