OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-dd message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-dd] RE: Issue 130 - DPWS - Fault Handling ClarificationNeeded


Hi Travis-

Since a HOSTED SERVICE’s types are advertised in metadata, I’m not sure how the service would not know whether it supports a specific Action.  I could understand that a Subscription Manager would not know the Actions supported by a service, but the Subscribe is sent directly to the service.

 

The text here reads like a “MAY” hidden as an implementation decision: if you decide to support this restriction (by wiring Actions into your Subscribe handler), you MUST issue the fault.  The restriction should be clear on this: it should be a MAY, a SHOULD, or a MUST, and it should be driven by the requirements we have for the protocol.  If we need this part of the protocol, it’s up to implementers to figure out how to provide it.  If we don’t need it, we should relax the restriction.

 

Services should absolutely have a way to express that they don’t support an Action, so we should definitely not remove the definition.  The difference between “MAY,” “SHOULD,” and “MUST” is whether clients need this fault.

 

If clients need to know that their Action filter was invalid, the requirement should be a MUST.  It is up to implementers to figure out how to accommodate this.

If clients do not need to know that their Action filter was invalid, this requirement can be a MAY or a SHOULD.  If the fault is optional, why do we need the text that requires it to be sent in place of a SubscribeResponse?

 

Thanks

--D

 

From: Travis M Grigsby [mailto:travisg@us.ibm.com]
Sent: Thursday, January 08, 2009 10:19 AM
To: Dan Driscoll
Cc: Ram Jeyaraman; ws-dd@lists.oasis-open.org
Subject: Re: [ws-dd] RE: Issue 130 - DPWS - Fault Handling Clarification Needed

 


Hi Dan -
        My concern with not including some additional description is that the normative text implies that an implementation MUST know about all of  its events in advance, which isn't true in all cases.  I'm not particularly attached to the explanatory paragraph, but I do think we should try to make it known that there is more than one way to approach this.  

How about changing the normative text to something closer to below?  

R3020:  If all of the Action URI's are known to a HOSTED SERVICE at subscribe time, and none of the Action URI's 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.

Have a great day!
Travis


Travis M. Grigsby
SWG Emerging Standards
(512) 591-2571



From:

Dan Driscoll <Dan.Driscoll@microsoft.com>

To:

Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>, "ws-dd@lists.oasis-open.org" <ws-dd@lists.oasis-open.org>

Date:

01/07/2009 09:49 PM

Subject:

[ws-dd] RE: Issue 130 - DPWS - Fault Handling Clarification Needed

 






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:Dan.Driscoll@microsoft.com]
Sent: Monday, January 05, 2009 5:54 PM
To: Ram Jeyaraman; ws-dd@lists.oasis-open.org
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:Ram.Jeyaraman@microsoft.com]
Sent: Tuesday, December 16, 2008 8:17 AM
To: ws-dd@lists.oasis-open.org
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:travisg@us.ibm.com]
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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]