[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Issue pr008 - WS-Discovery - Clarifications to ad hoc andmanaged mode definitions
|
I propose a slight rewording to the proposed changes in WS-Discovery
section 2.2.3. The changes are in red: 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” -----Original Message----- Note from issue submitter attached. -----Original Message----- From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] Sent: Friday, April 03, 2009 1:55 PM To: ws-dd@lists.oasis-open.org Subject: [ws-dd] Issue pr008 - WS-Discovery -
Clarifications to ad hoc and managed mode definitions This issue is assigned the number pr008. For further
discussions on this issue, please refer to this issue number or use this
thread. -----Original Message----- 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) -- This publicly archived list offers a means to provide
input to the OASIS Web Services Discovery and Web Services Devices Profile
(WS-DD) TC. In order to verify user consent to the Feedback License
terms and to minimize spam in the list archive, subscription is required before
posting. Subscribe: ws-dd-comment-subscribe@lists.oasis-open.org Unsubscribe:
ws-dd-comment-unsubscribe@lists.oasis-open.org List help: ws-dd-comment-help@lists.oasis-open.org List archive:
http://lists.oasis-open.org/archives/ws-dd-comment/ Feedback License:
http://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines:
http://www.oasis-open.org/maillists/guidelines.php Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-dd --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the
OASIS TC that generates this mail. Follow this link to all your TCs in
OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]