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

Yves,

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

Cheers,

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 
also
> > to the thread on the differences between one way and request/response. 
I'm
> > 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 
wired 
> to always have a response, then changing to "ah you _may_ have a 
response" 
> 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. 
Nothing
changes there. I don't see that as a conformance change. Clearly, the 
application
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 
on 
> 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 
argument
in the past. But frankly, at this point they become "mostly harmless" and 
hence, 
to make the changes less substantial, we can, IMO, leave them be without 
creating 
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 
client 
> 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 
just 
> 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."
>