[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-dd] Issue 024 - DPWS - R1013 and R1015 should clarifydirected discovery
|
Updated proposed text (changes in grey): R1015: A DEVICE MUST support
receiving a unicast Probe SOAP ENVELOPE as an HTTP Request at any HTTP transport address
where the DEVICE endpoint is available. R????: A DEVICE MAY reject a unicast Probe SOAP ENVELOPE received
as an HTTP Request if the [address] property of the [destination]
is not “urn:docs-oasis-open:ws-dd:discovery:2008:09”. To support the scenario where a DEVICE has a known HTTP transport address, a
CLIENT may send an ad-hoc Probe over HTTP to that address and expect to receive
a Probe Matches
response, using the same
message pattern as defined by the ProbeOp operation of the DiscoveryProxy
portType. This requirement does not imply that the DEVICE must perform as
a Discovery Proxy. How the
CLIENT obtains the DEVICE HTTP address is not defined in this specification,
and this HTTP address does not necessarily related to HOSTED SERVICE addresses. R1021: If a DEVICE matches a
Probe SOAP ENVELOPE received as an HTTP Request, it MUST send a Probe Matches SOAP ENVELOPE response containing a Probe
Match section representing the DEVICE. R1022: If a DEVICE does not
match a Probe SOAP ENVELOPE received as an HTTP Request, it MUST send a Probe Matches
SOAP ENVELOPE response with no Probe Match sections. -----Original Message----- I agree that this should be as compact and clear as
possible. 2006/02 DPWS packaged WS-D messages (Probe/PM) into an
operation. Technically we should have included a WSDL for this, since this
pattern wasn't present in WS-D. We could continue to do the same, although we
would have to copy out the text that describes the request/response pattern,
and define a portType. It seems to me to be simpler to describe the necessary
portType to implement, and then restrict it down to only apply to
Probe/ProbeMatches. You're right that this isn't completely clear, but it
avoids the evil of having to duplicate work in DPWS that is already done in
WS-D. --D -----Original Message----- From: Antoine Mensch [mailto:antoine.mensch@odonata.fr] Sent: Wednesday, October 29, 2008 1:22 AM To: ws-dd@lists.oasis-open.org Subject: Re: [ws-dd] Issue 024 - DPWS - R1013 and R1015
should clarify directed discovery I think the reference to ad-hoc in the proposed
resolution is somewhat misleading. Refering only to Probe messages should be
enough. Cheers Antoine Ram Jeyaraman a écrit : > > This issue is assigned the number 024. For further
discussions on this > issue, please refer to this issue number or use this
thread. > > *From:* Dan Driscoll > *Sent:* Wednesday, September 17, 2008 9:32 AM > *To:* Ram Jeyaraman > *Subject:* NEW Issue - DPWS - R1013 and R1015 should
clarify directed > discovery > > Please defer discussions on this issue until a time
this issue is > accepted and is assigned a number. > > *Description:* > > DPWS Section 4 (Discovery) describes a method of
sending WS-Discovery > messages over an HTTP connection. This
request/response exchange is > not described in WS-Discovery, and does not conform
to the SOAP 1.2 > HTTP binding. > > A proposed issue in WS-Discovery (Issue 022) adds a
request/response > MEP for communicating to discovery proxies that is
similar in > functionality to this exchange. > > Additionally, the specification is unclear about the
HTTP addresses at > which a device must support receiving this Probe
message. > > *Proposed Resolution:* > > DPWS should reuse the WS-Discovery request/response
proxy pattern for > use with directed discovery to a known HTTP
endpoint. > > · R1015 should require devices to implement the
"proxy" side of the > proposed WS-Discovery request/response pattern.
R1015 should also > require that devices support receiving a directed
Probe at any HTTP > addresses where the device endpoint is available.
The supporting text > should clarify that the device may also accept these
Probes at other > locations. > > /R1015: A DEVICE MUST support receiving an ad-hoc
Probe SOAP ENVELOPE > as an HTTP Request at any HTTP addresses where the
DEVICE endpoint is > available./ > > / / > > Clients may query a known HTTP endpoint for devices
by sending an > ad-hoc WS-Discovery Probe message in the HTTP
request/response pattern > described in WS-Discovery section xxx. > > / / > > · R1021 and R1022 should be updated to match the
request/response pattern. > > /R1021: If a DEVICE matches a Probe SOAP ENVELOPE
received as an HTTP > Request, it MUST send a Probe Match SOAP ENVELOPE in
the HTTP Response./ > > / / > > /R1022: If a DEVICE does not match a Probe SOAP
ENVELOPE received as > an HTTP Request, it MUST send a Probe Match SOAP
ENVELOPE in the HTTP > Response with no ProbeMatch sections in the SOAP
body./ > > · Add the following clarifying text at the end of
section 4: > > How the CLIENT obtains the DEVICE HTTP address is
not defined in this > specification, and this HTTP address does not
necessarily relate to > HOSTED SERVICE addresses. > >
------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.169 / Virus Database: 270.6.21/1676 -
Release Date: 17/09/2008 09:33 > > --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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]