RE: [wsn] Potential issue on WS-BaseNotif

[Steve Graham <sggraham@us.ibm.com>]

David:
Yes, that would be the clarification,
I too mapped "softening" in the way you suggested.

++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++

"David Orchard" <dorchard@bea.com> 06/17/2004 06:06 PM

To:        Steve Graham/Raleigh/IBM@IBMUS, "Vambenepe, William N" <vbp@hp.com>         cc:        <wsn@lists.oasis-open.org>         Subject:        RE: [wsn] Potential issue on WS-BaseNotif

I'm not quite sure what "softening"
means, whether that means adding outcomes or changing the MUST to a MAY.
 Pressing valiantly onwards, my suggestion would be that the wording
says something like:
The NotificationProducer MUST
create a Subscription resource representing the Subscription or generate
a FAULT.  It returns an EndpointReference or a Fault in the response
to the Subscribe request.
 
Cheers,
Dave
-----Original Message-----
From: Steve Graham [mailto:sggraham@us.ibm.com]
Sent: Thursday, June 10, 2004 6:15 PM
To: Vambenepe, William N
Cc: wsn@lists.oasis-open.org
Subject: Re: [wsn] Potential issue on WS-BaseNotif


I agree the wording could be improved to state that the production of an
EPR to a subscription is the result of successful processing of the subscribe
request. 

++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++

"Vambenepe, William N" <vbp@hp.com> 06/10/2004 05:53 PM

To:        <wsn@lists.oasis-open.org>        cc:                Subject:        [wsn] Potential issue on WS-BaseNotif

Hi all,

Alan Weissberger pointed a potential issue in WS-BaseNotification:

Section 4.2 says: "As part of the processing of a Subscribe request
message, the NotificationProducer MUST create a Subscription resource
representing the Subscription. It returns an EndpointReference in the
response to the Subscribe request."

This does not leave the option to refuse to create this subscription, if
for example the NotificationProducer does not support the topic
requested, or the subscriber does not have adequate permissions or the
NotificationProducer has reached max capacity or any other reason.

The suggestion is to soften the wording to allow this and to define
fault message(s) to express this.

Any comment or opposition to adding this as an issue?

Regards,

William