← Prev in month ← Prev in thread
Next in thread → Next in month →

RE: [ws-dd-comment] FW: WS-DD 1.1 2009/01; Issue PR004

From
Toby Nixon <>
Date
2009-04-06T22:48:52+00:00
ID
Thread
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:] 

Sent:
Thursday, February 26, 2009 6:43 PM

To:


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

 
|  www.microsoft.com | V: +1 425
706 2792  |  M: +1 206 790 6377  |  F: +1 425 708 4811
← Prev in month ← Prev in thread
Next in thread → Next in month →