- From: Doug Davis <dug@us.ibm.com>
- Date: Tue, 12 Jan 2010 14:30:54 -0500
- To: public-ws-resource-access@w3.org
- Message-ID: <OF82FDCC4B.1DA05015-ON852576A9.0069E42E-852576A9.006B37E2@us.ibm.com>
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 Tuesday, 12 January 2010 19:31:56 UTC