W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2006

Re: Regrets for 1 Feb XMLP Telcon (was: Re: Comments on the "drop response-only" Part 2 draft)

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Tue, 31 Jan 2006 10:29:22 -0500
To: Yves Lafon <ylafon@w3.org>
Cc: Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, xml-dist-app@w3.org, xml-dist-app-request@w3.org
Message-ID: <OF08008E4D.811CDF1C-ON85257107.0053DC2E-85257107.0055163F@us.ibm.com>

I'm not sure I would agree. Please see inlined comments below.


Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

xml-dist-app-request@w3.org wrote on 01/30/2006 12:20:15 PM:

> On Wed, 25 Jan 2006, noah_mendelsohn@us.ibm.com wrote:
> >> but must send regrets for next week.
> >
> > I'm afraid that still holds.  I hope you will all give serious
> > consideration to my comments and conclusions posted today at [1], and 
> > to the thread on the differences between one way and request/response. 
> > increasingly convinced that the position I took in my original note 
[2] is
> > pretty close to correct as stated, both as general philospophy and as
> > specifically applied to HTTP (see especially [3]).  Thanks.
> My position is that replacing Request/Response by something that has 
> options. If you have a program that use Request Response and is hard 
> to always have a response, then changing to "ah you _may_ have a 
> is a big conformance change.

Changing the **binding** to r-o-r doesn't necessarily change the semantics
of the application that sits above the SOAP processing/transport binding.
If the application expects a response, then clearly the application at the
other end is obligated to send one, and the binding can accomodate. 
changes there. I don't see that as a conformance change. Clearly, the 
would be broken if it didn't honor the application-level semantic embodied
in its contract (e.g. WSDL). We aren't changing that.

> Also if we push a bit the optional request/optional response, to do 
> something like request*/response*, we define a MEP that covers all kind 
> interaction that may happen between two nodes (including multicast).
> In that case, MEPs are no longer useful and should be removed.

I'm not going to argue with this point, because I have made a similar 
in the past. But frankly, at this point they become "mostly harmless" and 
to make the changes less substantial, we can, IMO, leave them be without 
any problems.

> The fact that some implementation may be using one way messaging in HTTP 

> in the current framework needs to be addressed, but if it disrupts the 
> current understanding of MEPs, then this case needs to be addressed with 

> the implementers to fix issues like the a-priori knowledge from the 
> of the MEP used. And the fact that the one way MEP is done as "fire and 
> forget" or with ackowledgement that the message has been received is 
> a property of the "transport" used, but it doesn't change the overall 
> meaning of the MEP a the SOAP level.
> -- 
> Yves Lafon - W3C
> "Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Tuesday, 31 January 2006 15:29:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:29 UTC