Re: Issue 7970

Wu,
  could you elaborate a bit on your thinking here.  If we went with the 
2nd option (which seemed to be preferred on the call):
   A Web service that accepts requests to create subscriptions for
   a certain set of notification that might be generated.

what woud need to change in your implementation or what would break in any 
existing implementation?

Also, your point #3 actually might not be true.  If WS-Eventing doesn't 
define an Event Source to allow for other components (anything other than 
the _one_ event source) to send Notifications then an extension spec can't 
do it either since it would be contradicting the base spec. 

As it currently stands we have an inconsistency in the spec - if Event 
Sources are the only things that can send Notifications, then when we use 
a pull-style model we're broken because in those cases the Subscription 
Manager is the one that sends the Notifications.  I don't think the above 
proposal would break anyone, nor even require a coding change.  Rather its 
just an admission that our WS-* specs only control what goes on the wire 
and we can't control what happens behind the scenes.  How people choose to 
implement this stuff is up to them.  For example, there is nothing 
inWS-Addressing that requires the sender of an async response to be the 
same entity as the one that received the request and this is no different. 
 Do we really need to say that the entity that sends the SubscribeResponse 
MUST be the same one the receives the SubscribeRequest?  And what does 
"same one" mean?  In a clustered environment things get a bit complicated.

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
10/26/2009 10:23 AM

To
"Bob Freund" <bob.freund@hitachisoftware.com>, 
<public-ws-resource-access@w3.org>, 
<public-ws-resource-access-request@w3.org>
cc
"Li, Li (Li)" <lli5@avaya.com>
Subject
Issue 7970






Bob,
We see some problems with issue 7970 [1] and we share our thoughts below.
1) 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 proposal involves 
interactions with some entity whose behavior is not defined in the spec. 
2) By allowing an unknown third-party (instead of event source) to send 
notifications to event sink complicates security checks against attacks to 
the event sink. For example, IP blocking would not work since the true 
notification senders are unknown, even after the subscription. 
3) Current WS-Eventing architecture can handle this use case by having the 
event source forward notifications (from other senders) to the sinks. 
Therefore, alternative approaches should be treated as extensions.
Thanks,
- Wu Chou/Li Li, 
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=7970