Minutes of MEP Task Force 2004-11-23

Minutes of MEP Task force 2004-11-23 are at
http://www.w3.org/2004/11/23-ws-desc-minutes.htm
and also below in plain text.


===================================================================

   [1]W3C

      [1] http://www.w3.org/

                         WS Description MEP Task Force

23 Nov 2004

   See also: [2]IRC log

      [2] http://www.w3.org/2004/11/23-ws-desc-irc

Attendees

   Present
          Jonathan_Marsh, Dbooth, Roberto, Glen, Canon, Amelia_Lewis

   Regrets

   Chair
          JMarsh

   Scribe
          dbooth

Contents

     * [3]Topics
         1. [4]The in-out Pattern
     * [5]Summary of Action Items

     _________________________________________________________________

The in-out Pattern

   <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)".

   dbooth: Yes

   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.

   [Meeting adjourned]

Summary of Action Items

     _________________________________________________________________


    Minutes formatted by David Booth's [6]scribe.perl 1.95 ([7]CVS log)
    $Date: 2004/11/23 18:01:42 $

      [6] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribe.perl
      [7] http://dev.w3.org/cvsweb/2002/scribe/scribe.perl


-- 

David Booth
W3C Fellow / Hewlett-Packard

Received on Tuesday, 23 November 2004 18:02:21 UTC