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

You're right. I was focusing too much on this one aspect 
(SubscriptionEnd) and not thinking about all the other messages that 
might not get sent in this situation.

I still have some editorial tweaks to Ram's wording. Here's my version:

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

- gp

On 1/14/2010 4:33 PM, Doug Davis wrote:
>
> Hey Gil,
>   recall that earlier in the week there was a thread on this topic 
> where we talked about how this situation is pretty much true for any 
> outgoing message. If the service crashes, or is going down, any 
> pending outgoing message might not be able to be sent.  So, in that 
> respect SubscriptionEnd isn't special.  There's an implied "out" in 
> all of the WS* specs that the "MUST be sent" type of requirements 
> really only apply as long as the endpoint is able to (ie. isn't dead 
> ;-)  - I think Ram used the term "best effort".  So, I think the text 
> Ram was proposing works.
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
> The more I'm around some people, the more I like my dog.
>
>
> *Gilbert Pilz <gilbert.pilz@oracle.com>*
>
> 01/14/2010 06:30 PM
>
> 	
> To
> 	Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
> cc
> 	Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" 
> <public-ws-resource-access@w3.org>
> Subject
> 	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> 
> [_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_ 
> <mailto: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]
>