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

Proposed concrete edits:
http://www.w3.org/2002/ws/ra/10/01/wseventing-8286.html
http://www.w3.org/2002/ws/ra/10/01/wsenum-8286.html

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 09:37 PM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
public-ws-resource-access@w3.org
Subject
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] 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
The more I'm around some people, the more I like my dog. 

Ram Jeyaraman <Ram.Jeyaraman@microsoft.com> 
01/12/2010 12:48 PM 


To
Doug Davis/Raleigh/IBM@IBMUS, "Li, Li (Li)" <lli5@avaya.com> 
cc
"public-ws-resource-access@w3.org" <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] On Behalf Of Doug Davis
Sent: Tuesday, January 12, 2010 8:00 AM
To: Li, Li (Li)
Cc: 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
The more I'm around some people, the more I like my dog. 

"Li, Li (Li)" <lli5@avaya.com> 
Sent by: public-ws-resource-access-request@w3.org 
01/12/2010 10:43 AM 
  


To
<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> on Tue, 5 Jan 
2010 14:24:57 -0800 ----- 

To: 
Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
cc: 
"public-ws-resource-access@w3.org" <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] On Behalf 
Of bugzilla@wiggum.w3.org
Sent: Friday, November 13, 2009 1:44 PM
To: 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
      ReportedBy: gilbert.pilz@oracle.com
       QAContact: 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] 

Received on Friday, 15 January 2010 18:11:40 UTC