See also: IRC log
<Marsh> Great, thanks!
<Marsh> My email is still syncing up though...
<Marsh> And my phone is making phreakie noises
<Marsh> Least I'm not late :-)
<Marsh> I guess I should dial into my other conf number too and see if anyone is lurking there...
<scribe> Scribe: dbooth
GlenD: Extensions can do what they want, so we could use a stricter sense of the MEP, and permit the WS-Addressing extension to modify those semantics.
... But in a SOAP extension, you'd now need to understand the binding in order to understand the meaning of the interface. That's a more general problem. Many SOAP-specific extensions could change the meaning at the abstract level.
Roberto: Can't limit that, but shouldn't recommend it as a solution.
... That should be the exception.
dbooth: Yes, the interface would be saying one thing, and the binding would say something different.
GlenD: If we go to the more general MEP, then everyone will use that and if the response goes back to the original sender, that will be an optimization.
Roberto: We've been talking about a node permitting multiple physical addresses, but not change the ultimate recipient, so it wouldn't prevent using WS-Addressing.
JMarsh: What do we need to change in our spec?
Roberto: The current (tight) pattern would permit many cases, and we could adopt another pattern for the other cases.
Amy: If the point is to send a response back to the original requester, then the current MEP is ok. If the redirect can go anywhere, then it ought to have the more general MEP.
... The requester sets the response destination to be something that it will see. If you want is somewhere else, it should use a different MEP.
dbooth: Sanjiva's position is that if the WSDL doc says the response is going back to the *same* node, then no matter where it redirects the response, it should be considered to be a part of the same node.
Amy: Fine, but if it's going back somewhere else, then it needs a different pattern.
GlenD: A code gen example would be illustrative. If you're using the tight MEP, then you can use a code style of "Result = callService(inMessage)".
Roberto: The endpoint, if invoked on an in-out and it's given an in-out that is not acceptable as an alternate address for the same client node, then it should be able to fault.
GlenD: But how could it know that it isn't the same client node?
dbooth: If the originating client says to redirect the response somewhere else, then it is delegating authority to that other agent to act on its behalf. Therefore it still is part of the same logical node.
Amy: If the service has some way of independently verifying that the requesting and response destination node are NOT the same, then it should be able to fault.
dbooth: If the client delegates authority to that other node, how can you say it isn't the same logical node?
Amy: Could prohibit delegation.
dbooth: Yes, but that gets into a grey area of what is considered delegation. Is *any* use of Reply-To considered delegation?
Roberto: Would be good to fault if the service detects an invalid use of the MEP, it should fault.
Amy: Just because the WSDL says the response is going back to the same node, that doesn't mean that it actually is. WS-Addressing could redirect it somewhere else.
dbooth: Then how do you know whether the response is going back to the same node?
GlenD: I don't see how we could prevent the response from going somewhere else.
... SOAP uses a URI to identify the node. Even if that recipient is on Mars, if it recognizes that URI, then it's the same node.
Roberto: What if the service can't trust the client?
... MEP should say if you use in-out, then the reply SHOULD go to the same node, and if there's a violation, then it's ok to fault.
Amy: I'm opposed to that.
dbooth: Who is in a better position to know what physical addresses are really a part of the client node? The client or the service?
(Heated debate about whether the service can know more than the client
<jjm> +1 to Amy's summary
We all seem to agree that a client should be able to direct responses to other physical addresses without being considered a different MEP, but the service SHOULD be able to fault. The disagreement is about how to characterize the reason for the fault.
<jjm> Yeap. I don't think we should require MEP validation.
dbooth thinks that only the client can say who is authorized to act on the client's behalf, but the service may have a policy that prohibits certain kinds of delegation of authority.
Therefore, when the service faults because it is given a Reply-To address that it doesn't permit, then that fault should be considered a violation of a service policy -- not an MEP violation.
Amy thinks that there are cases when the service knows better than the client about what physical addresses the client has authorized to act on its clients behalf, and therefore the service may be able to detect that the Reply-To address is not a part of the same logical client node. Thus, it should be characterized as an MEP violation.