- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 14 Jan 2009 19:12:21 +0000
- To: public-ws-resource-access-notifications@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6432
Summary: WS-Eventing Push delivery mode does not work when the
subscriber is not addressable
Product: WS-Resource Access
Version: FPWD
Platform: PC
OS/Version: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: Eventing
AssignedTo: public-ws-resource-access-notifications@w3.org
ReportedBy: geoffbu@microsoft.com
from: public list:
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jan/0019.html
Hi,
My name is Antoine Mensch and I am a member of the OASIS WS-DD TC
working on the Devices Profile for Web Services (DPWS). We've
implemented WS-Eventing as part of DPWS for quite some time now, and we
have run into the following issue:
Description:
The WS-Eventing default delivery mode (used in DPWS) is based on a push
mechanism that requires the event source to connect to the subscriber to
deliver the event notification. This creates problems in two very common
cases:
(i) when the subscriber is behind a firewall using NAT;
(ii) when the subscriber is a Web application (e.g. Ajax or Java, Flash
or Silverlight applets) which cannot accept incoming connections.
Although the first problem can sometimes be solved using dynamic port
mapping, the second one normally requires a change to the default
security policy of the Web browser, which is generally not acceptable.
Proposed resolution:
Introduce a special URL to be used as the [address] of the notifyTo /
endTo endpoint references in the Subscribe message. This special URL
would inform the event source/subscribtion manager that event
notifications are not to be sent directly to the subscriber, but rather
that the subscriber will initiate a connection to fetch them. The
proposed mechanism could work in a way similar to the one described in
the WS-MakeConnection specification.
Best regards,
Antoine Mensch
Odonata
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Received on Wednesday, 14 January 2009 19:12:31 UTC