Re: issue 7970: new proposal

Wu,
  please elaborate on this trust model you are reading into the spec - I 
don't see it.  I think those questions I asked need to be answered.

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.



"Chou, Wu (Wu)" <wuchou@avaya.com> 
Sent by: public-ws-resource-access-request@w3.org
11/05/2009 04:41 PM

To
<public-ws-resource-access@w3.org>
cc

Subject
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> 
Date: Thu, 5 Nov 2009 08:42:51 -0500
To: "Chou, Wu (Wu)" <wuchou@avaya.com> 
Cc: public-ws-resource-access@w3.org 
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
The more I'm around some people, the more I like my dog.



"Chou, Wu (Wu)" <wuchou@avaya.com> 
Sent by: public-ws-resource-access-request@w3.org
11/05/2009 03:14 AM

To
<public-ws-resource-access@w3.org>
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
 
From: Doug Davis <dug@us.ibm.com> 
Date: Tue, 3 Nov 2009 17:04:32 -0500
To: public-ws-resource-access@w3.org 
Message-ID: 
<OF513C87BC.9B42A3B9-ON85257663.0078FA0C-85257663.0079457E@us.ibm.com> 
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
The more I'm around some people, the more I like my dog.