Re: What Problem are we trying to solve Rev 1 note new A7

As far as clarifying "reply" and "response", I'd suggest:

   1. Reply: A non-fault message sent to the [reply endpoint] and
      conforming to the rules in section 3.4 of the core.
   2. Fault: A SOAP fault message sent to the [fault endpoint] and
      conforming to the rules in section 3.4 of the core.
   3. Response: A reply or fault, as defined above
   4. Response endpoint: The [reply endpoint] and [fault endpoint]
      collectively


Note that (4) is already in place, in the SOAP binding.  The rules in
section 3.4 would have to be retitled "Formulating a /response/ message".

Bob Freund wrote:
>
> This is a list of the results, as I heard them, of our discussion on
> 2006-10-02 related to our response to CR33 and amended based on the
> discussions of the 2006-10-09 distributed meeting
>
>  
>
> Exposition:
>
> It seems that the desire inferred by the issue is that an endpoint
> would like to transmit identifying information (or perhaps some other
> parametric information) in a one way message, and that one way message
> is intended to be used to "open the backchannel" upon which may be
> transmitted information that is determined in part by the identifying
> or parametric information transmitted in the originating message.  In
> the specific use case presented, the issue originator proposes that
> this identifying or parametric information be passed in the replyTo
> uri as a special form of "anonymous".  CR33 states that the
> WS-Addressing WSDL binding CR document would create interoperability
> issues with their implementation since it does not permit a form of
> anonymous other than the literal "anonymous" to be represented in WSDL.
>
>  
>
> In the WS-Addressing Teleconference of 2006-10-02, there was a
> brainstorming session intended to clarify exactly what problem the
> WS-Addressing working group was trying to solve related to its
> resolution of CR33 since several proposals related to a direct
> response to CR33 have failed as yet to gain consensus.
>
>  
>
> Alternatives mentioned: (please feel free to come up with more if you
> have a better idea)
>
>  
>
> A1) During the progress of the WS-Addressing working group, a feature
> known as Reference Properties was removed from the original
> submission.  If this were to be added back, then this could be used to
> convey such identifying or parametric information.  This would imply
> changes to both rec level specifications as well as the WSDL binding. 
> It is not clear if these might be "breaking changes".
>
>  
>
> A2) The WS-Addressing specifications include a feature known as
> Reference Parameters which are created by the epr minter which are
> considered to be "opaque" to all but the minter.  Outside of the
> WS-Addressing "layer" there may be no such constraint.  Reference
> Parameters might be used to convey this identifying or parametric
> information.  Note that there is not general agreement that
> WS-Addressing is a "layer" or if it is a set of kit parts which may be
> used at any layer. This might imply a clarifying change to
> WS-Addressing specifications.
>
>  
>
> A3) WS-Addressing includes a feature known as "From" which contains a
> uri.  There are no behavioral constraints imposed by "From" and
> potentially anything that might be represented as a uri might be
> conveyed. This might imply a clarifying change to WS-Addressing
> specifications.
>
>  
>
> A4) WS-Addressing defined a limited set of special URLs which mean
> specific things to WS-Addressing when used in replyTo.  These are
> "anonymous" and "none".  If the behavior specified by WS-Addressing is
> not desired, then the authors of other specifications might specify
> their own forms of replyTo semantics appropriate to their application
> without WS-Addressing implications.  This would imply that CR33 be
> closed with no action.
>
>  
>
> A5) It was suggested that there is wide latitude in what might be
> contained in a SOAP header and the authors might be able to use such a
> means to convey the desired identifying or parametric information.
> This would imply that CR33 be closed with no action.
>
>  
>
> A6) WS-Addressing Core and SOAP binding are fine as-is, but we just
> need to fix the WSDL binding or perhaps come up with a WSDL cum policy
> related change.  For proposals related to this alternative, please
> refer to the issue list. 
>
>  
>
> A7) The usage scenario can be accomplished through the use of
> wsa:RelatesTo in conjunction with the wsa:RelationshipType
> extensibility point provided in the WS-Addressing core specification
> to define a domain specific relationship type.  This option requires
> no change to the rec level documents.
>
>  
>
> For the purposes of this thread please identify in the subject line
> the alternative A[1-n] referenced or "exposition" if you feel the
> problem statement needs improvement.
>
>  
>
> Miscellaneous comments:
>
> It seems that there is at least two areas of the WS-Addressing specs
> that might be clarified once we see our way through this maze.
>
> 1)       Usage of the words reply and response seem to be variously
> interpreted to mean the specific application response to THIS message
> rather than a returned soap body that was stimulated by THIS message
> but that might relate to some other message.
>
> 2)       If the WG settles on a rejection of section 5.2.1 advice
> concerning the potential of other forms of anonymous then that section
> ought to be amended accordingly.  Conversely if the WG re-affirms that
> section, then it ought to embrace that decision appropriately in the
> WSDL binding such that full use of the core and SOAP bindings are
> supported.
>
>  
>
> Thanks
>
> -bob
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>