Re: issue 7970: new proposal

Doug,
 
I think the current WS-E spec is very clear, as you noted in your new
proposal "Also, as I was reviewing ws-eventing I noticed some other
places where we talk about the event source being the one to send
notifications".
 
Notification operation is in the event source wsdl (or expressed in its
notification wsdl) of that event source endpoint.  By definition of wsdl
and using the same wording of Kitty's for issue 7921, "If the feature
WSDL defines a concrete endpoint, then this endpoint MUST be used for
the feature operations" i.e. using it for notification. I don't think
there is any confusion in current WS-E spec, and this is the kind of
trust built into the semantics of wsdl. I don't think we need to add/do
anything beyond that.
 
Allowing event notification be sent from some unknown opaque soap node
not from the event source is an extension. We need to clearly specify it
and this is the motivation of our proposal with event dispatcher to
address this issue.
 
Thanks, 
 
- Wu Chou.
 
Wu Chou, IEEE Fellow, Ph.D. | Director |Dialogue System Research | AVAYA
| 233 Mt. Airy Road| Rm. 2D48 | Basking Ridge, NJ 07920 | Voice/Fax:
908-696-5198 / 908-696-5401 | wuchou@avaya.com 
 
From: Doug Davis <dug@us.ibm.com
<mailto:dug@us.ibm.com?Subject=Re%3A%20issue%207970%3A%20new%20proposal&
In-Reply-To=%253COF936D17CD.565F00F9-ON85257665.00497C03-85257665.004B58
09%40us.ibm.com%253E&References=%253COF936D17CD.565F00F9-ON85257665.0049
7C03-85257665.004B5809%40us.ibm.com%253E> > 
Date: Thu, 5 Nov 2009 08:42:51 -0500
To: "Chou, Wu (Wu)" <wuchou@avaya.com
<mailto:wuchou@avaya.com?Subject=Re%3A%20issue%207970%3A%20new%20proposa
l&In-Reply-To=%253COF936D17CD.565F00F9-ON85257665.00497C03-85257665.004B
5809%40us.ibm.com%253E&References=%253COF936D17CD.565F00F9-ON85257665.00
497C03-85257665.004B5809%40us.ibm.com%253E> > 
Cc: public-ws-resource-access@w3.org
<mailto:public-ws-resource-access@w3.org?Subject=Re%3A%20issue%207970%3A
%20new%20proposal&In-Reply-To=%253COF936D17CD.565F00F9-ON85257665.00497C
03-85257665.004B5809%40us.ibm.com%253E&References=%253COF936D17CD.565F00
F9-ON85257665.00497C03-85257665.004B5809%40us.ibm.com%253E>  
Message-ID:
<OF936D17CD.565F00F9-ON85257665.00497C03-85257665.004B5809@us.ibm.com> 

Wu,
  let's back up a bit here.  Currently "Event Source" is defined as:
        Event Source: A Web service that sends notifications and accepts

requests to create subscriptions. 

There are at least two interpretations of this one sentence:
1 - its an abstract concept and the exact topology and structure of the 
event source is an implementation choice.  While there is a single EPR
for 
incoming messages, outgoing messages are free to be sent from any 
component within the implementation of the event source.
2 - its a single endpoint that must be used for all incoming and
outgoing 
messages. 

Clearly if there's more than one way to read this then we have a
potential 
interop problem and it needs to be cleared up in the spec.  In your note

below you talk about a trust relationship/model that is not mentioned 
within the spec.  If we were to adopt your reading of this definition
then 
we would need to add more information to the spec to make sure that
there 
is no ambiguity around how to interpret this definition.  Can we first 
focus on defining this trust model?  In particular can you write up some

text for the spec that clearly articulates this trust model?  Based on 
what you've said so far it seems that it would need to include things 
like: scope of an event source; relationship between the event source
EPR 
and the IP addresses of machines sending async notifications;
restrictions 
on what those IP addresses can be; what the limits are w.r.t. IP address

changes (ie. can the DNS record of foo.com be updated to a new IP
address 
during the lifetime of a subscription); what are the security mechanisms

that are implied or required to be supported (e.g. IP filtering - while 
optional for a sink, you're requiring a source to live within those
rules 
and that needs to be written down) - stuff like that. 

I think once we have this definition written down we'll be able to make 
better progress on finding a complete resolution.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
<mailto:dug@us.ibm.com?Subject=Re%3A%20issue%207970%3A%20new%20proposal&
In-Reply-To=%253COF936D17CD.565F00F9-ON85257665.00497C03-85257665.004B58
09%40us.ibm.com%253E&References=%253COF936D17CD.565F00F9-ON85257665.0049
7C03-85257665.004B5809%40us.ibm.com%253E> 
The more I'm around some people, the more I like my dog.



"Chou, Wu (Wu)" <wuchou@avaya.com
<mailto:wuchou@avaya.com?Subject=Re%3A%20issue%207970%3A%20new%20proposa
l&In-Reply-To=%253COF936D17CD.565F00F9-ON85257665.00497C03-85257665.004B
5809%40us.ibm.com%253E&References=%253COF936D17CD.565F00F9-ON85257665.00
497C03-85257665.004B5809%40us.ibm.com%253E> > 
Sent by: public-ws-resource-access-request@w3.org
<mailto:public-ws-resource-access-request@w3.org?Subject=Re%3A%20issue%2
07970%3A%20new%20proposal&In-Reply-To=%253COF936D17CD.565F00F9-ON8525766
5.00497C03-85257665.004B5809%40us.ibm.com%253E&References=%253COF936D17C
D.565F00F9-ON85257665.00497C03-85257665.004B5809%40us.ibm.com%253E> 
11/05/2009 03:14 AM

To
<public-ws-resource-access@w3.org
<mailto:public-ws-resource-access@w3.org?Subject=Re%3A%20issue%207970%3A
%20new%20proposal&In-Reply-To=%253COF936D17CD.565F00F9-ON85257665.00497C
03-85257665.004B5809%40us.ibm.com%253E&References=%253COF936D17CD.565F00
F9-ON85257665.00497C03-85257665.004B5809%40us.ibm.com%253E> >
cc

Subject
Re: issue 7970: new proposal

This new proposal is a major change to the current WS-E spec semantics, 
and it raises some critical issues (sorry to be repetitive since there
is 
no indication how these issues can be addressed in this new proposal).
 
1. It breaks the trust relation between event source and the subscriber.

Under this new proposal, a  subscriber subscribes to a trusted event 
source will make it open to arbitrary unknown source, including not 
trusted ones. The current WS-E spec makes sure that a subscription to a 
trusted event source will get events delivered from that trusted event 
source and no where else. 
 
This new change may cause serious concerns by enterprise IT. This change

is similar to modify http protocol to allow a response of http GET to a 
trusted web site coming back from an arbitrary unknown place, other than

the one that GET request is addressed to. All IT security measures of 
IP-blocking, firewall filtering, etc. have to change and make them open
to 
allow unknown source to get in.
 
2. It breaks the poll-model event delivery, since the event subscriber 
does not know where to poll event from as the event dispatcher is
unknown 
and arbitrary.
 
3. The event subscriber cannot be sure if it can receive event 
notification after a successful event subscription, as event can be sent

from some unknown/not trusted host and blocked by firewall, even the 
subscription is sent to a trusted site.
 
4. Current WS-Eventing is based on a set of well-defined web services 
(source, sink, subscriber and subscription manager). If there is some 
entity that interacts with WS-Eventing services, it should be either 
defined in the spec, or it should be out of scope. This new proposal 
involves interactions with an unknown entity during the protocol 
negotiation. This is problematic and not declarative.
 
Thanks,
 
- Wu Chou.
 
Wu Chou, IEEE Fellow, Ph.D. | Director |Avaya Labs Research | AVAYA |
233 
Mt. Airy Road| Rm. 2D48 | Basking Ridge, NJ 07920 | Voice/Fax: 
908-696-5198 / 908-696-5401 | wuchou@avaya.com <mailto:wuchou@avaya.com>

 
From: Doug Davis <dug@us.ibm.com
<mailto:dug@us.ibm.com?Subject=Re%3A%20issue%207970%3A%20new%20proposal&
In-Reply-To=%253COF936D17CD.565F00F9-ON85257665.00497C03-85257665.004B58
09%40us.ibm.com%253E&References=%253COF936D17CD.565F00F9-ON85257665.0049
7C03-85257665.004B5809%40us.ibm.com%253E> > 
Date: Tue, 3 Nov 2009 17:04:32 -0500
To: public-ws-resource-access@w3.org
<mailto:public-ws-resource-access@w3.org?Subject=Re%3A%20issue%207970%3A
%20new%20proposal&In-Reply-To=%253COF936D17CD.565F00F9-ON85257665.00497C
03-85257665.004B5809%40us.ibm.com%253E&References=%253COF936D17CD.565F00
F9-ON85257665.00497C03-85257665.004B5809%40us.ibm.com%253E>  
Message-ID: 
<OF513C87BC.9B42A3B9-ON85257663.0078FA0C-85257663.0079457E@us.ibm.com
<mailto:OF513C87BC.9B42A3B9-ON85257663.0078FA0C-85257663.0079457E@us.ibm
.com?Subject=Re%3A%20issue%207970%3A%20new%20proposal&In-Reply-To=%253CO
F936D17CD.565F00F9-ON85257665.00497C03-85257665.004B5809%40us.ibm.com%25
3E&References=%253COF936D17CD.565F00F9-ON85257665.00497C03-85257665.004B
5809%40us.ibm.com%253E> > 
After some talks with Ram about this one, we came up with a new proposal

that should allow the usecase I'm concerned about to work while still 
allowing for the event source to be the one to send out notifications:
- - - - - -
Event Source 
A Web service that accepts requests to create subscriptions. 

Notification 
A one-way message sent to indicate that an event, or events, have 
occurred. Notifications MAY be sent by any endpoint including the event 
source. 
- - - - - - - 

Also, as I was reviewing ws-eventing I noticed some other places where
we 
talk about the event source being the one to send notifications - we 
should change those too: 

During that time, notifications are delivered by the event source to the

requested event sink... 
-- s/by the event source// 

the event source sends only notifications that match the requested
filter 
-- change to: only notifications that match the requested filter are
sent 
-- actually, we should change "notifications" to "events" too since we 
don't filter notifications, we filter events 

The event source sends notifications until ... 
-- change to: Notifications are sent until... 

This specification defines a method for transmitting notifications from 
the event source to the event sink through the use of the wse:NotifyTo 
element. 
-- s/from the event source// 

I don't think these changes any have normative impact on the spec or 
coding changes.  It just avoid any confusion that they might cause. 

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
<mailto:dug@us.ibm.com?Subject=Re%3A%20issue%207970%3A%20new%20proposal&
In-Reply-To=%253COF936D17CD.565F00F9-ON85257665.00497C03-85257665.004B58
09%40us.ibm.com%253E&References=%253COF936D17CD.565F00F9-ON85257665.0049
7C03-85257665.004B5809%40us.ibm.com%253E> 
The more I'm around some people, the more I like my dog.