RE: Minutes of MEP Task Force 2004-11-23

Well, I actually had a conflict and sent a message to Jonathan yesterday. FYI. 

--umit

>-----Original Message-----
>From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] 
>Sent: Tuesday, Nov 23, 2004 10:02 AM
>To: www-ws-desc@w3.org
>Subject: 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 20:23:04 UTC