[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]