[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Issue 124 - WS-Discovery - xAddrs in ResolveMatches issue
Please review the proposal for resolving this issue. The proposal is in conjunction with the resolution of issue 125.
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.
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]
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 Section
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.
Resolve Match Section
This issue is assigned the number 124. For further discussions on this issue, please refer to this issue number or use this thread.
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.
· 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.