[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-dd-comment] FW: WS-DD 1.1 2009/01; Issue PR004
Dear
Mr. Treptow: Thank
you very much for submitting your comment on WS-Discovery during the current
public review period regarding Section 4.1.3, Discovery Proxy. It was assigned
issue number PR004 for tracking purposes. The
issue contains two points. The first point suggests adding a statement to
clarify that “[H]ello should be sent regardless of any Type or Scopes
that might be in the request”. The TC examined the language in the fourth
bullet of 4.1.3, and decided that the word “any” in the phrase “In
response to any
multicast Probe (or multicast Resolve) from a Client” is sufficiently
clear and that no additional statement is needed. The
second point suggests adding language to spell out certain specific behaviors
of a “discovery proxy” such as responding to multicast Probe
messages on behalf of Target Services on other subnets. The TC considered this
suggestion, but decided not to add any additional material to the
specification. The WS-Discovery specification defines the roles Discovery Proxy
and Target Service in terms of their Port Types, focusing on the wire protocol rather
than the functionality or features of software implementing these roles. The
scenario you describe is certainly valid and can be addressed by the current
protocol specification. An application can implement the Target Service role
for services in different subnets; it can send multicast announcements on
behalf of services in other subnets and respond to multicast Probe and Resolve
messages on behalf of those services, as if those services are present on the
current subnet. Such an application is using the Target Service port type for such
communications, acting as an “agent” of services on other subnets.
The same application can also implement the Discovery Proxy role as described
in the specification. However, it is beyond the scope of WS-Discovery to fully
describe how the various roles described in the specification might be combined
to produce a complete product (such as the various ways a proxy application
might become aware of services on other subnets). The TC chose not to venture beyond
protocol specifications and into writing product specifications, and thus
declined to accept this suggestion. Because
neither of the points raised were accepted by the TC, issue PR004 was moved to
the Dropped state. Thanks
again for your interest and suggestions. Best
regards, Toby
Nixon Co-Chair,
OASIS WS-DD Technical Committee From:
Jay A. Treptow [mailto:jay@treptows.net] Sent:
Thursday, February 26, 2009 6:43 PM To:
ws-dd-comment@lists.oasis-open.org Subject:
[ws-dd-comment] FW: WS-DD 1.1 2009/01 Below
are comments on the Web Services Dynamic Discovery (WS-Discovery) Version 1.1
Public Review Draft 01 28 January 2009. In
section ‘4.1.3 Discovery Proxy’, bullet four, you might consider a
statement that clarifies that the hello should be sent regardless of any Type
or Scopes that might be in the request. At first I thought that the Hello
should only be sent in response to a Probe or Resolve for d:DiscoveryProxy type
requests. Additionally,
I can see how the Hello response reduces network traffic for discovery proxy
aware clients (Win7), but I think that it misses a use case for non discovery
proxy aware clients (Vista). If a target service on subnet A provisions a
discovery proxy on subnet B via a managed mode Hello, then any non discovery proxy
aware clients on network B will not discover the target
service. You
might consider stating that the proxy MAY return ProbeMatch or ResolveMatch
elements for target services that were provisioned via managed mode, or for all
target services where their XAddrs are on a different subnet from where the
Probe was received. 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]