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: Issue 084 - DPWS - Service Subscribe Fault Clarification


We had a discussion about this on the last conference call, and I’ve put together an updated proposal.

 

Text in red is new.  This change would add two explanatory paragraphs, and a new restriction (currently marked as R????; I’ll give this a real number when it’s added into the spec).


R3017: If a HOSTED SERVICE does not understand the [address] of the Notify To of a Subscribe SOAP ENVELOPE, the HOSTED SERVICE MUST generate a wsa:DestinationUnreachable SOAP Fault in place of a SubscribeResponse.

R3018: If a HOSTED SERVICE does not understand the [address] of the End To of a Subscribe SOAP ENVELOPE, the HOSTED SERVICE MUST generate a wsa:DestinationUnreachable SOAP Fault in place of a SubscribeResponse.

R3017 and R3018 do not ensure that a HOSTED SERVICE can contact an event sink, but they do provide a mechanism for the event source to fault on unsupported URI schemes or addresses it knows it cannot contact.

 

R????: If a HOSTED SERVICE generates a wsa:DestinationUnreachable SOAP Fault under R3017 or R3018, the SOAP Fault Detail MUST be the EndTo or NotifyTo Endpoint Reference Address that the HOSTED SERVICE did not understand.

 

R???? allows a client to distinguish between a SOAP Fault generated due to an unreachable [destination] information header in the Subscribe message, and a SOAP Fault generated due to an unreachable NotifyTo or EndTo address.

 

 

From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
Sent: Monday, November 17, 2008 7:31 AM
To: ws-dd@lists.oasis-open.org
Subject: [ws-dd] Issue 084 - DPWS - Service Subscribe Fault Clarification

 

This issue is assigned the number 084. For further discussions on this issue, please refer to this issue number or use this thread.

 

From: Scott de Deugd [mailto:dedeugd@us.ibm.com]
Sent: Sunday, November 16, 2008 6:18 PM
To: Ram Jeyaraman
Cc: Doug Davis; Travis M Grigsby
Subject: New WS-DD Issue: Service Subscribe Fault Clarification

 

 

Document: DPWS 1.1-spec-wd-02-1
Line number:  Line 813,816
Owner: Scott de Deugd
Service Subscribe Fault Clarification

Description:
Editorial: Section 6.1 says:
R3017: If a HOSTED SERVICE does not understand the [address] of the Notify To of a Subscribe SOAP ENVELOPE, the HOSTED SERVICE MUST generate a wsa:DestinationUnreachable SOAP Fault.

R3018: If a HOSTED SERVICE does not understand the [address] of the End To of a Subscribe SOAP ENVELOPE, the HOSTED SERVICE MUST generate a wsa:DestinationUnreachable SOAP Fault.".

If the NotifyTo is checked after the subscribeResponse message is sent then the client may never know that the subscription is broken and will never send any notifications.  A message may be able to get to the EndTo EPR but that is optional and may not be included since its optional, but eve nthen it will probably be the same EPR as the NotifyTo – and there fore probably be bad too.  The Subscription manager would silently terminate the subscription and the subscriber will never know that their subscription was missed.

Proposed Resolution (changes in red):
R3017: If a HOSTED SERVICE does not understand the [address] of the Notify To of a Subscribe SOAP ENVELOPE, the HOSTED SERVICE MUST generate a wsa:DestinationUnreachable SOAP Fault in place of a SubscribeResponse.

R3018: If a HOSTED SERVICE does not understand the [address] of the End To of a Subscribe SOAP ENVELOPE, the HOSTED SERVICE MUST generate a wsa:DestinationUnreachable SOAP Fault in place of a SubscribeResponse.

The details of the fault sent back to the client needs to reference the bad EPR - otherwise people may think it was the wsa:To of the Subscribe. Performing a check during the Subscribe does not prevent the possibility of an EndTo or NotifyTo URI becoming unreachable at a later point in time. However, doing such a check during Subscribe may be useful in detecting erroneous URIs or unsupported transports.



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