Please review the proposal for
resolving this issue. The proposal is in conjunction with the resolution of
issue 125.
Vipul
----
Moved the conceptual message
content paragraph from ad-hoc mode sub-section to separate sub-section in Section
3 as it applies to both ad-hoc and managed mode. In addition to the
modifications shown below the figure was modified to indicate that a Probe
Match provides both EPR and transport addresses.
Conceptual Message Content
Conceptually, Hello, Probe Match, and Resolve Match contain
different kinds of information as Figure 3 depicts.
Figure 3 : Conceptual content of messages.
Starting at the top of Figure 3, Probe maps from Types
and/or Scopes to an Endpoint Reference [WS-Addressing];
and one or more transport addresses (see Section 3.1
Endpoint References). Though though
not depicted, Hello also provides an Endpoint Reference. Resolve maps this
the Endpoint Reference to one or more transport addresses (see Section 3.1 Endpoint References). Other address
mappings may be needed, e.g., DNS, but are beyond the scope of this
specification.
The required components of each message are defined in
detail below, but as an optimization, a Target Service may short-circuit these
message exchanges by including additional components; for instance, a Probe
Match Hello may contain transport address(es) along with an Endpoint
Reference, or a transport address may use an IP address instead of a DNS name.
Probe Match Section
/s:Envelope/s:Body/d:ProbeMatches/d:ProbeMatch/d:XAddrs
Transport
address(es) that MAY be used to communicate with the Target Service (or
Discovery Proxy). Contained URIs MUST NOT contain white space. If a Target
Service (or Discovery Proxy) has transport addresses (see Section 3.1 Endpoint
References) at least one transport address MUST be included. If omitted or
empty, no implied value. See /s:Envelope/s:Body/*/d:XAddrs in Section
5.1 Hello.
Resolve Match Section
/s:Envelope/s:Body/d:ResolveMatches/d:ResolveMatch/d:XAddrs
As constrained for Probe Match (see
Section 6.3 Probe Match). See
/s:Envelope/s:Body/*/d:XAddrs in Section 5.1 Hello.
From: Ram Jeyaraman
[mailto:Ram.Jeyaraman@microsoft.com]
Sent: Tuesday, December 16, 2008 8:09 AM
To: ws-dd@lists.oasis-open.org
Subject: [ws-dd] Issue 124 - WS-Discovery - xAddrs in ResolveMatches
issue
This issue is assigned the number 124. For further
discussions on this issue, please refer to this issue number or use this
thread.
From: Dan Driscoll
Sent: Monday, December 15, 2008 8:41 PM
To: Ram Jeyaraman
Subject: NEW issue: WS-D xAddrs in ResolveMatches issue
Physically addressed services that do not have distinct
xAddrs are currently forced to generate an empty xAddrs element or produce no
ResolveMatches at all in response to a Resolve for their EPR.
Since not all clients have the same understanding of
physical addresses as services (some clients may know nothing about HTTP, for
instance) Target Services need a way to generate meaningful ResolveMatches messages
without including empty elements. That way, they can inform clients that
their EPR should be interpreted as a physical address.
Proposed change:
·
Make xAddrs optional in ResolveMatches schema
(add ‘minOccurs=”0”’)
·
Craft some language that makes xAddrs mandatory
in ResolveMatches if the service has xAddrs. I’ll work with Vipul
to build this.