- From: Doug Davis <dug@us.ibm.com>
- Date: Fri, 8 Jan 2010 17:03:07 -0500
- To: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
- Cc: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <OF4A88CF61.4C44E1E2-ON852576A5.0078F9C7-852576A5.00792751@us.ibm.com>
That very subjective. To you Filtering is critical - to someone else
being able to know for sure when and why a subscription ends might be just
as critical. GetStatus is not a sufficient replacement fro EndTo -
GetStatus will never tell you why a subscription terminated prematurely.
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/08/2010 04:59 PM
To
Doug Davis/Raleigh/IBM@IBMUS
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Subject
RE: [Bug 8286] New: description of Subscription End ambiguous
Since it is not possible to set up a successful subscription without
honoring the filtering requirements, it makes sense to reject a
subscription request with FilteringNotSupported fault.
But the availability of EndTo and support for SubscriptionEnd operation is
not critical since the client can use GetStatus to find out the same. The
current behavior allows clients to interact with services with different
capabilities and vice versa; this is particularly useful in cases where
the client and service do not live in a controlled environment. Attempting
to match capabilities of clients that do or do not support EndTo with
services that do or do not support SubscriptionEnd is quite complex and it
makes the simple case very complex.
Thanks.
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Friday, January 08, 2010 12:32 PM
To: Ram Jeyaraman
Cc: public-ws-resource-access@w3.org
Subject: RE: [Bug 8286] New: description of Subscription End ambiguous
Why do we have a FilteringNotSupported fault then? That's an optional
element and an optional feature - yet we tell the subscriber that we don't
support it. By your first sentence we should silently ignore the Filter
element if we don't support it, and we should ignore any unknown filter
dialects - after all, they're optional.
Its not clear to me why we would not want to be user-friendly and let a
subscriber know that what they asked for will not be adhered to. We're
not talking about an extension (which can be silently ignored w/o an mU=1
type of flag), we're talking about something that is defined by the base
spec.
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>
Sent by: public-ws-resource-access-request@w3.org
01/08/2010 03:20 PM
To
Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" <
public-ws-resource-access@w3.org>
cc
Subject
RE: [Bug 8286] New: description of Subscription End ambiguous
The notion of optionality implies duality, that is, SubscriptionEnd may or
may not be supported. Further, such optional behavior should not affect
normal processing.
>From a client subscriber perspective, optionality means the following:
1. The Subscribe request containing an EndTo is accepted normally
(that is, the subscription is NOT rejected because the event source cannot
support SubscriptionEnd).
2. It MAY receive a SubcriptionEnd if the event source is capable of
sending SubscriptionEnd. No guarantees.
Based on this, I do not see a reason to fault a Subscribe containing an
EndTo when the event source does not support SubscriptionEnd. This allows
the clients to function as intended irrespective of whether an optional
behavior is supported or not by the service.
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 05, 2010 6:04 PM
To: public-ws-resource-access@w3.org
Subject: Re: [Bug 8286] New: description of Subscription End ambiguous
+1
http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jan/0009.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>
Sent by: public-ws-resource-access-request@w3.org
01/05/2010 05:24 PM
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.
Received on Friday, 8 January 2010 22:04:08 UTC