- From: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
- Date: Fri, 27 Jan 2006 14:46:37 +0100
- To: noah_mendelsohn@us.ibm.com
- Cc: David Orchard <dorchard@bea.com>, Mark Baker <distobj@acm.org>, "Patrick R. McManus" <mcmanus@datapower.com>, Rich Salz <rsalz@datapower.com>, xml-dist-app@w3.org
May I dare a summary? So a FAF MEP would not really be FAF at the HTTP (and lower) level, but it would nonetheless provide a useful abstraction (and fit well to other transports). The MEP user will not (have to) care and the MEP implementor will simply have to obey the HTTP semantics and discard the HTTP response. Am I getting anywhere close to reality? JJ. PS. Thanks to Noah, David, Mark, Patrick, Rich (and others I probably forget [sic]) for an enlightening discussion. noah_mendelsohn@us.ibm.com wrote: >David Orchard writes: > > > >>More to the point, I don't see why we'd need an request-optional- >>soap-response mep AND a f-a-f mep where f-a-f is interpreted as you >>suggested on the server. >> >> > >..because when we implement SOAP on true FAF transports like UDP, and >maybe some flavors of Jabber (I have to go back and look at that) we'll >want the true FAF MEP and probably not the Req/Resp (I.e. because >Req/Resp, as we keep reminding ourselves, requires the transport to know >how to address responses, which in general UDP does not provide.) FAF is >the natural MEP and should be used on one-way transports; Req/Resp and/or >Response-only (which is more properly named >Request/ResponseWithEnvelopeInResponseOnly) are the natural MEPs and >should be used on Request/Response protocols like HTTP. > >-------------------------------------- >Noah Mendelsohn >IBM Corporation >One Rogers Street >Cambridge, MA 02142 >1-617-693-4036 >-------------------------------------- > > > > > > >
Received on Friday, 27 January 2006 13:46:56 UTC