Also, I’d like to add a concrete proposal to the mail below: I
propose that we accept the normative change to R3020, but not add the
explanatory paragraph.
From: Dan Driscoll
[mailto:]
Sent: Monday, January 05, 2009 5:54 PM
To: Ram Jeyaraman;
Subject: [ws-dd] RE: Issue 130 - DPWS - Fault Handling Clarification
Needed
The normative addition makes sense—we don’t want services to
send a SubscribeResponse if the subscription failed, or if the service intends
to fault immediately afterward.
I prefer that the spec stay silent on the case where the service
does not know about its own events ahead of time. I expect many
implementers wire the list of Actions into their Subscribe handler specifically
to handle this case (and that’s a good thing), so anyone who doesn’t feel like
plumbing this list into Subscribe could arguably be in a “dynamic environment”
where they don’t know what events are available when they receive the
Subscribe.
That said, I realize there are very valid technical reasons why
the service may not know at Subscribe time, but I prefer that those
implementers deal with that on a case-by-case basis.
The current pattern is very simple, and lets higher-layer specs
be very straightforward about how they define optional events without having to
worry about the case where the service may be in a “dynamic environment.”
Thanks Travis
--D
From: Ram Jeyaraman
[mailto:]
Sent: Tuesday, December 16, 2008 8:17 AM
To:
Subject: [ws-dd] Issue 130 - DPWS - Fault Handling Clarification Needed
This issue is assigned the number 130. For further
discussions on this issue, please refer to this issue number or use this
thread.
From: Travis M Grigsby
[mailto:]
Sent: Tuesday, December 16, 2008 8:05 AM
To: Ram Jeyaraman
Cc: Scott de Deugd; Doug Davis; Mike Kaiser
Subject: WS-DD Issue: Fault Handling Clarification Needed
Hello Ram - I
had an issue to add! Please let me know if this needs further
clarification.
Subscription
Filter - Fault Handling Clarification Needed
Description:
Document:
DPWS 1.1-spec-wd-02-1
Line
number: Line 889
Owner:
Travis Grisby:
Section 6.1.1
says:
R3020: If
none of the Notifications exposed by a HOSTED SERVICE match the [action] values
in a Subscribe SOAP ENVELOPE Filter whose Dialect is "http://schemas.xmlsoap.org/ws/2006/02/devprof/Action", the HOSTED
SERVICE MUST generate a wsdp:FilterActionNotSupported SOAP Fault.
When should this
be raised? During a subscribe?
Does this
imply that an event sink must know all of the types of notifications its going
to send?.
Proposed Resolution (changes in red):
In
some dynamic environments, it may not be possible for a HOSTED SERVICE to
determine a complete list of possible events and actions prior to generating
them. In the event that the list is known, it is important to check this
list against the filter provided in the Subscribe message in order to notify
the subscriber immediately of an erroneously specified filter.
R3020:
If none of the Notifications exposed by a HOSTED SERVICE match the [action]
values in a Subscribe SOAP ENVELOPE Filter whose Dialect is "http://schemas.xmlsoap.org/ws/2006/02/devprof/Action", the HOSTED
SERVICE MUST return a wsdp:FilterActionNotSupported
SOAP Fault instead of a SubscribeResponse.
Thanks!
Travis
Travis M.
Grigsby
SWG Emerging Standards
(512) 591-2571
