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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-dd-comment message

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


Subject: RE: [ws-dd-comment] NEW Issue: Ad Hoc and Managed for DiscoveryProxy (Issue PR008)


Dear Mr. Schmutzler:

 

Thank you very much for your comment on the Public Review of the WS-Discovery specification. It was assigned the number PR008 for tracking purposes.

 

The TC has discussed your comment, and we appreciate your participation in further discussions on the issue raised and proposed resolution. Based on these discussions, the TC has agreed to add text to Section 2.2.3 of WS-Discovery as follows (insertions shown >>in red between angle brackets<<):

 

“However, if one or more DP >>that provide multicast suppression<< are available, those DP send a unicast >>Hello that contains information on an endpoint that implements<< a well-known "discovery proxy" type d:DiscoveryProxy >>in managed mode<< in response to any multicast Probe or Resolve. As depicted in Figure 4, Clients listen for this signal that one or more DP are available, and for subsequent searches switch to a managed mode and instead of multicast, send Probe and Resolve messages unicast to one or more DP they trust whilst ignoring multicast Hello and Bye from Target Services”

 

This change is reflected in the latest working draft of WS-Discovery. The TC agrees that this does not constitute a Substantive Change that would necessitate additional public review.

 

Thank you again for your help in improving the clarity of the WS-Discovery specification.

 

Best regards,

 

Toby Nixon

Co-Chair, OASIS WS-DD Technical Committee

 

 


 

From: Jens Schmutzler [mailto:jens.schmutzler@uni-dortmund.de]

Sent: Friday, April 03, 2009 6:58 AM

To: ws-dd-comment@lists.oasis-open.org

Cc: Damien.LAVAUX@fr.thalesgroup.com

Subject: [ws-dd-comment] NEW Issue: Ad Hoc and Managed for Discovery Proxy

 

Hi Everyone,

 

Please defer discussions on this issue until a time this issue is accepted

and is assigned a number.

 

Document: Web Service Dynamic Discovery (WS-Discovery) V1.1 Public Review

Draft

(http://docs.oasis-open.org/ws-dd/discovery/1.1/pr-01/wsdd-discovery-1.1-spe

c-pr-01.pdf)

Location (defaults to line number): Multiple occurrences

Owner: Jens Schmutzler

 

 

The definition of the Ad-Hoc and Managed Mode is slightly misleading in the

current draft:

 

A Client being capable of the Dynamic Switching Mode (section 2.2.3) would

never(!) switch from Ad-Hoc to Managed Mode if it joins a network where a

Discovery Proxy (DP) is running in Managed Mode (see section 5.2.3). The

current draft of the spec only specifies a DP-Hello in response to

Client-Side Multicast Probe for the DP in Ad-Hoc mode (see section 5.2.3).

 

The current wording does not explicitly exclude this behaviour, but the

following wording would improve consistency of the specification, as it

applies this behaviour to both Ad-Hoc and Managed Mode for the DP and not

only to the Ad-Hoc mode. It basically moves the second bullet point from the

Ad Hoc mode to the top in order to be applicable for both modes.

 

Proposed Resolution:

 

Proposed wording for 5.2.3 (from line 950):

"

A Discovery Proxy MAY be configured to reduce multicast traffic on both ad

hoc and managed networks, in this capacity, a Discovery Proxy MUST listen

for multicast Probe for other Target Services and respond to them with a

Hello message as described in Section 4.1.3 Discovery Proxy.

 

In an ad hoc mode,

- A Discovery Proxy MUST listen for multicast Probe messages for itself and

respond as described in Section 5.3.2 Discovery Proxy.

 

In a managed mode,

- A Discovery Proxy MUST listen for unicast Probe request and respond to

them as described in Section 5.3.2 Discovery Proxy. 

"

 

Same change would also apply to sections:

- 5.3.2 (Probe Match - Discovery Proxy)

- 6.2.3 (Resolve - Discovery Proxy)

- 6.3.2 (Resolve Match - Discovery Proxy)

 

Consequently section 4.1.3 and 4.2.3 also need to be reordered:

 

Proposed wording for 4.1.3 (from line 633):

"

- A Discovery Proxy MAY be configured to reduce multicast traffic on both ad

hoc and managed networks, in this capacity:

-  A Discovery Proxy MUST listen for multicast Hello messages and store (or

update) information for the corresponding Target Services.

-  A Discovery Proxy MUST listen for multicast Probe (and Resolve). In

response to any multicast Probe (or multicast Resolve) from a Client, a

Discovery Proxy MUST send a unicast Hello to the Client and SHOULD send the

Hello without waiting for a timer to elapse.

 

In an ad hoc mode,

- A Discovery Proxy MUST send a Hello for itself (as a Target Service of

d:DiscoveryProxy type) as described in Section 4.1.1 Target Service.

 

In a managed mode,

- A Discovery Proxy MUST listen for unicast Hello messages and store (or

update) information for the corresponding Target Services.

"

 

Proposed Wording for 4.2.3 (from line 775):

"

- A Discovery Proxy MAY be configured to reduce multicast traffic on both ad

hoc and managed networks, in this capacity:

-  A Discovery Proxy MUST listen for multicast Bye messages, marking or

removing corresponding information as invalid. 

 

In an ad hoc mode,

- A Discovery Proxy SHOULD send a Bye for itself (as a Target Service of

d:DiscoveryProxy type) when it is preparing to leave the network as

described in Section 4.2.1 Target Service.

 

In a managed mode,

- A Discovery Proxy MUST listen for unicast Bye messages, marking or

removing corresponding information as invalid.

"

 

Alternatively, section 2.2 could state that the Discovery Proxy always MUST

implement both Ad Hoc and Managed Modes. Then and only then the following

sections would be consistent with section 2.2 to 2.2.3.

 

We are currently in the development of a Discovery Proxy for the SOA4D

DPWS4J stack following the draft specification, where we stumbled across

this issue.

 

Thanks a lot for all the good work in the WS-DD TC!

 

Best Regards,

 

Jens Schmutzler (member of the IST-MORE consortium)

 

--

Dipl.-Ing. Jens A. Schmutzler

 

Communication Networks Institute (CNI)

Dortmund University of Technology

Otto-Hahn-Str. 6

44227 Dortmund

Germany

 

Room: C1-04-176

Fon: +49 (231) 755-3781, Fax: -6136

EMail: jens.schmutzler@tu-dortmund.de

Web: (www.cni.tu-dortmund.de)

 

 

Toby Nixon  |  Senior Standards Program Manager  |  Windows Device and Storage Technologies  |  Microsoft Corporation

toby.nixon@microsoft.com  |  www.microsoft.com | V: +1 425 706 2792  |  M: +1 206 790 6377  |  F: +1 425 708 4811

 



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