Re: [Bug 8286] New: description of Subscription End ambiguous

Ram,

I'm having a bit of trouble sorting out who's text is who below. In any 
case, I object to the following:

If the event source terminates a subscription unexpectedly, it supports 
wse:EndTo semantics, and the wse:EndTo EPR was present in the Subscribe 
message for that subscription (see 4.1 Subscribe), the SubscriptionEnd 
message MUST be sent to the endpoint referenced by that EPR. The message 
MUST be of the following form:

You brought up the case in which an Event Source is terminated (kill -9) 
before it has the chance to send any/all of the SubscriptionEnd messages 
for its active subscriptions. I think this is an realistic scenario and 
we need to allow for it. Specifically Subscribers/Event Sinks need to be 
aware that even if (a) the Event Source supports EndTo and (b) the 
Subscriber includes EndTo in the Subscribe request and (c) EndTo is 
valid, reachable, etc. - there is still a possibility that they might 
not get a SubscriptionEnd message due to the circumstances above.

I suggest:

If the Event Source terminates a subscription unexpectedly, and it 
supports the use of wse:EndTo, and the wse:EndTo EPR was present in the 
Subscribe message for that subscription (see 4.1 Subscribe), the 
SubscriptionEnd message SHOULD be sent to the endpoint referenced by 
that EPR. The message MUST be of the following form:

Note there are circumstances (e.g. the forcible termination of the Event 
Source) under which it might not be possible for the Event Source to 
transmit the SubscriptionEnd message.

- gp

On 1/14/2010 12:31 PM, Ram Jeyaraman wrote:
>
> Agree with the direction. Some suggestions below.
>
> Ø 1 - add <wse:EndToSupported .../>? to the Eventing policy assertion 
> as a parameter (after wse:FormatName).
>
> */wse:EventSource/wse:EndToSupported *
>
> When present, this OPTIONAL parameter indicates support for the 
> /wse:Subscribe/wse:EndTo semantics. That is, when a subscription 
> request contains an wse:EndTo element, a SubscriptionEnd message will 
> be sent to the EPR contained in the wse:EndTo element, if the 
> subscription terminates unexpectedly.
>
> Ø 2 - add <xs:element name='EndToSupported' type='tns:Empty' 
> minOccurs='0'/>  to the eventing xsd after def'n of FormatName param.
>
> Yes.
>
> Ø 4 - define a new fault "EndToNotSupported" for cases where an EndTo 
> is passed in on the Subscribe but the source doesn't support it
>
> *6.11 EndToNotSupported*
>
> This fault is generated by an event source that does not support 
> /wse:Subscribe/wse:EndTo semantics, in response to a subscription 
> request that contains an wse:EndTo element.
>
> *[Code]*
>
> 	
>
> s12:Sender
>
> *[Subcode]*
>
> 	
>
> wse:EndToNotSupported
>
> *[Reason]*
>
> 	
>
> wse:EndTo semantics is not supported.
>
> *[Detail]*
>
> 	
>
> /none/
>
> Ø 5 - add text for the new fault under the def'n of EndTo in the 
> Subscribe section:
>         If the event source does not support the use of the EndTo EPR, 
> the event source MUST generate a wse:EndToNotSupported fault.
>
> Yes.
>
> Ø 3 - modify section 4.5 from:
>         If the event source terminates a subscription unexpectedly, a 
> SubscriptionEnd SOAP message SHOULD be sent to the endpoint reference 
> indicated when the subscription was created (see 4.1 Subscribe). This 
> endpoint reference MUST refer to an endpoint that supports the 
> SubscriptionEndPortType portType. Support for including the EndTo EPR 
> in a Subscribe request message (and implicitly the sending of the 
> SubscriptionEnd message) MUST be supported by compliant event sources. 
> The message MUST be of the following form:
>
> to
>
>         If the event source terminates a subscription unexpectedly, 
> EndTo is supported, and the wse:EndTo EPR was present in the Subscribe 
> message for that subscription (see 4.1 Subscribe), the SubscriptionEnd 
> message MUST be sent to the endpoint referenced by that EPR. The 
> message MUST be of the following form:
>
> Suggestion:
>
> If the event source terminates a subscription unexpectedly, it 
> supports wse:EndTo semantics, and the wse:EndTo EPR was present in the 
> Subscribe message for that subscription (see 4.1 Subscribe), the 
> SubscriptionEnd message MUST be sent to the endpoint referenced by 
> that EPR. The message MUST be of the following form:
>
> Thanks.
>
> *From:* public-ws-resource-access-request@w3.org 
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of *Doug 
> Davis
> *Sent:* Tuesday, January 12, 2010 11:31 AM
> *To:* public-ws-resource-access@w3.org
> *Subject:* RE: [Bug 8286] New: description of Subscription End ambiguous
>
>
> Looking at option 2 - I think it becomes:
> 1 - add <wse:EndToSupported .../>? to the Eventing policy assertion as 
> a parameter (after wse:FormatName).
> 2 - add <xs:element name='EndToSupported' type='tns:Empty' 
> minOccurs='0'/>  to the eventing xsd after def'n of FormatName param.
> 3 - modify section 4.5 from:
>         If the event source terminates a subscription unexpectedly, a 
> SubscriptionEnd SOAP message SHOULD be sent to the endpoint reference 
> indicated when the subscription was created (see 4.1 Subscribe). This 
> endpoint reference MUST refer to an endpoint that supports the 
> SubscriptionEndPortType portType. Support for including the EndTo EPR 
> in a Subscribe request message (and implicitly the sending of the 
> SubscriptionEnd message) MUST be supported by compliant event sources. 
> The message MUST be of the following form:
>
> to
>
>         If the event source terminates a subscription unexpectedly, 
> EndTo is supported, and the wse:EndTo EPR was present in the Subscribe 
> message for that subscription (see 4.1 Subscribe), the SubscriptionEnd 
> message MUST be sent to the endpoint referenced by that EPR. The 
> message MUST be of the following form:
>
> 4 - define a new fault "EndToNotSupported" for cases where an EndTo is 
> passed in on the Subscribe but the source doesn't support it
> 5 - add text for the new fault under the def'n of EndTo in the 
> Subscribe section:
>         If the event source does not support the use of the EndTo EPR, 
> the event source MUST generate a wse:EndToNotSupported fault.
> 6 - make similar edits to WS-Enumeration.
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  | dug@us.ibm.com <mailto:dug@us.ibm.com>
> The more I'm around some people, the more I like my dog.
>
> *Ram Jeyaraman <Ram.Jeyaraman@microsoft.com 
> <mailto:Ram.Jeyaraman@microsoft.com>>*
>
> 01/12/2010 12:48 PM
>
> 	
>
> To
>
> 	
>
> Doug Davis/Raleigh/IBM@IBMUS, "Li, Li (Li)" <lli5@avaya.com 
> <mailto:lli5@avaya.com>>
>
> cc
>
> 	
>
> "public-ws-resource-access@w3.org 
> <mailto:public-ws-resource-access@w3.org>" 
> <public-ws-resource-access@w3.org 
> <mailto:public-ws-resource-access@w3.org>>
>
> Subject
>
> 	
>
> RE: [Bug 8286] New: description of Subscription End ambiguous
>
>
> 	
>
>
>
>
> One of the reasons why a SHOULD is used for SubscriptionEnd message is 
> because it is possible that a service may suffer abrupt shutdown and 
> hence may not be able to send the terminal message. Besides, a service 
> simply may not support SubscriptionEnd.
>
> I can see two possible ways to tackle this issue:
>
> 1.        Keep it optional
> a.       Leave the specification as is -- that is, the SubscriptionEnd 
> SHOULD be sent.
>
> 2.       Keep it conditional [Gil's proposal (attached) as clarified 
> below]
> a.       Service behavior
>                                                                i.     
>  The enumeration data source may or may not support sending 
> EnumerationEnd.
>                                                              ii.     
>  If EnumerationEnd is supported, the data source will advertise this 
> via the enumeration policy.
>                                                            iii.     
>  If the service advertises support for EnumerationEnd and the client 
> sends EndTo, it must make a best attempt  to send EnumerationEnd.
>                                                            iv.      If 
> the service does NOT advertise support for EnumerationEnd and the 
> client sends EndTo, it must generate an SubscriptionEndNotSupported 
> fault.
> b.      Client behavior
>                                                                i.     
>  Depending on whether the service supports EnumerationEnd or not, the 
> client sends an EndTo.
>
> I am continuing to think about other possible ways.
>
> Thanks.
>
> *From:* public-ws-resource-access-request@w3.org 
> <mailto:public-ws-resource-access-request@w3.org> 
> [mailto:public-ws-resource-access-request@w3.org] 
> <mailto:[mailto:public-ws-resource-access-request@w3.org]> *On Behalf 
> Of *Doug Davis*
> Sent:* Tuesday, January 12, 2010 8:00 AM*
> To:* Li, Li (Li)*
> Cc:* public-ws-resource-access@w3.org 
> <mailto:public-ws-resource-access@w3.org>*
> Subject:* RE: [Bug 8286] New: description of Subscription End ambiguous
>
>
> Li,
>  I tend to agree.  I think there's always an implicit exception with 
> any MUST in the specs because if the system crashes and doesn't 
> recover its entire state then clearly the MUST will probably not 
> happen.  So I interpret these things as "if you're still up and 
> running then you MUST...".  The reason I was ok with calling out this 
> one case is because this message/situation is specifically for the 
> case where something really bad happened.  But, I can go with your 
> proposal to go with the MUST w/o the "unless..." part - it seems less 
> confusing.
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  | dug@us.ibm.com <mailto:dug@us.ibm.com>
> The more I'm around some people, the more I like my dog.
>
> *"Li, Li (Li)" <lli5@avaya.com <mailto:lli5@avaya.com>>*
> Sent by: public-ws-resource-access-request@w3.org 
> <mailto:public-ws-resource-access-request@w3.org>
>
> 01/12/2010 10:43 AM
>
> 	
>
> To
>
> 	
>
> <public-ws-resource-access@w3.org 
> <mailto:public-ws-resource-access@w3.org>>
>
> cc
>
> 	
>
> Subject
>
> 	
>
> RE: [Bug 8286] New: description of Subscription End ambiguous
>
>
>
> 	
>
>
>
>
>
> Eventing Current text:
> If the event source terminates a subscription unexpectedly, a
> SubscriptionEnd SOAP message SHOULD be sent to the endpoint reference
> indicated when the subscription was created (see 4.1 Subscribe). This
> endpoint reference MUST refer to an endpoint that supports the
> SubscriptionEndPortType portType.
>
> Proposal:
> If the event source terminates a subscription unexpectedly and the
> wse:EndTo EPR was present in the Subscribe message for that subscription
> (see 4.1 Subscribe), the SubscriptionEnd message MUST be sent to the
> endpoint referenced by that EPR unless the event source is incapable of
> transmitting any messages at all.
>
> I understand that the proposed change is to narrow the scope of
> exception to the requirement. However, I also feel that MUST + exception
> = SHOULD.
>
> I think MUST always means "absolute requirement" which may not be
> achieved by a conformant implementation due to unforeseen situations.
>
> If we adopt the proposal, should we also check exceptions to all MUST?
> For example, the (unless .... incapable ...) seems applicable to the
> following requirement in WS-E 4.1 as well:
>
> [Body]/wse:Subscribe/wse:Delivery/wse:NotifyTo
> This is an OPTIONAL element. When present, this element indicates that
> notifications MUST be sent to the EndpointReference identified by this
> element.
>
> I think it's better to just say MUST without any exception, or use
> SHOULD, but not the mixed.
>
> Thanks.
>
> Li
>
>
>
> ----- Message from Gilbert Pilz <gilbert.pilz@oracle.com 
> <mailto:gilbert.pilz@oracle.com>> on Tue, 5 Jan 2010 14:24:57 -0800 -----
>
> *To:*
>
> 	
>
> Ram Jeyaraman <Ram.Jeyaraman@microsoft.com 
> <mailto:Ram.Jeyaraman@microsoft.com>>
>
> *cc:*
>
> 	
>
> "public-ws-resource-access@w3.org 
> <mailto:public-ws-resource-access@w3.org>" 
> <public-ws-resource-access@w3.org 
> <mailto:public-ws-resource-access@w3.org>>
>
> *Subject:*
>
> 	
>
> Re: [Bug 8286] New: description of Subscription End ambiguous
>
>
> This is unacceptable because the Subscriber/Event Sink has no way of 
> knowing if SubscriptionEnd is supported. It supplies an EndTo EPR, the 
> Subscribe request succeeds, it gets some Notifications, then the 
> subscription terminates unexpectedly (something it doesn't know 
> about), then . . . nothing.
>
> If support for SubscriptionEnd is really optional (something I don't 
> remember to agreeing to - but my memory is shot), then it seems to me 
> that we should:
>
> 1.) Define a new fault for a Subscribe message that includes an EndTo 
> EPR along the lines of wse:SubscriptionEndNotSupported.
>
> 2.) Add a parameter to the wse:EventSource policy assertion that 
> indicates support for SubscriptionEnd.
>
> - gp
>
> On 1/3/2010 9:17 AM, Ram Jeyaraman wrote:
> I agree with this proposal except for the part where support for the 
> SubscriptionEnd operation is required. During our earlier 
> conversations, we determined that support for the SubscriptionEnd 
> operation is optional for the Event Source. Given that, I suggest an 
> amended proposal (change MUST to MAY):
>
> "If the event source terminates a subscription unexpectedly and the 
> wse:EndTo EPR was present in the Subscribe message for that 
> subscription (see 4.1 Subscribe), the SubscriptionEnd message MAY be 
> sent to the endpoint referenced by that EPR. The message MUST be of 
> the following form:"
>
> -----Original Message-----
> From: public-ws-resource-access-notifications-request@w3.org 
> <mailto:public-ws-resource-access-notifications-request@w3.org> 
> [mailto:public-ws-resource-access-notifications-request@w3.org] On 
> Behalf Of bugzilla@wiggum.w3.org <mailto:bugzilla@wiggum.w3.org>
> Sent: Friday, November 13, 2009 1:44 PM
> To: public-ws-resource-access-notifications@w3.org 
> <mailto:public-ws-resource-access-notifications@w3.org>
> Subject: [Bug 8286] New: description of Subscription End ambiguous
>
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=8286
>
> Summary: description of Subscription End ambiguous
> Product: WS-Resource Access
> Version: PR
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: normal
> Priority: P2
> Component: Eventing
> AssignedTo: public-ws-resource-access-notifications@w3.org 
> <mailto:public-ws-resource-access-notifications@w3.org>
> ReportedBy: gilbert.pilz@oracle.com <mailto:gilbert.pilz@oracle.com>
> QAContact: public-ws-resource-access-notifications@w3.org 
> <mailto:public-ws-resource-access-notifications@w3.org>
>
>
> Section 4.5 "Subscription End" starts with the following paragraph:
>
> "If the event source terminates a subscription unexpectedly, 
> SubscriptionEnd SOAP message SHOULD be sent to the endpoint reference 
> indicated when the subscription was created (see 4.1 Subscribe). This 
> endpoint reference MUST refer to an endpoint that supports the 
> SubscriptionEndPortType portType. The message MUST be of the following 
> form:"
>
> The "SHOULD" in this sentence is ambiguous. Does it refer to the act 
> of transmitting the message or does it refer to where the message is 
> transmitted?
> In both cases this should be a "MUST"; the SubscriptionEnd message 
> MUST be transmitted, and it MUST be transmitted to the endpoint 
> referenced by the EndTo EPR.
>
> The sentence "This endpoint reference MUST refer to an endpoint that 
> supports the SubscriptionEndPortType portType" is inappropriate and 
> redundant; this is a constraint on the event sink, not the event 
> source. This same constraint is already documented in the description 
> of /wse:Subscribe/wse:EndTo.
>
> Proposal: replace the above paragraph with the following:
>
> "If the event source terminates a subscription unexpectedly and the 
> wse:EndTo EPR was present in the Subscribe message for that 
> subscription (see 4.1 Subscribe), the SubscriptionEnd message MUST be 
> sent to the endpoint referenced by that EPR. The message MUST be of 
> the following form:"
>
>
> --
> Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
> ------- You are receiving this mail because: ------- You are the QA 
> contact for the bug.
> You are the assignee for the bug.
>
>
>  [attachment "smime.p7s" deleted by Doug Davis/Raleigh/IBM]
>