Re: Seeking clarification about the use of the HTTP binding

I agree that's a reasonable ex post facto explanation of the current
state of affairs, but I don't recall simplicity being an impetus for the
removal of the other response codes from the state transition table; as
I recall, the lone reason was "protocol independence".  I looked for
the discussion around this issue, but couldn't find it, and it's now
late on Friday.

FWIW though, I did find this[1] from Henrik which addresses an important
consideration; if 202 was used, the client can't expect the one-way MEP,
it can only learn of it after receiving the 202.  So if a 200 was
received instead, then the client would get the "real" response.  I
don't know how the MEP model would deal with this, but I'm not a big
fan of it anyhow, so I'll let WSD worry about that. 8-)

Cheers!

 [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0352.html

Mark.

On Fri, Nov 12, 2004 at 04:15:27PM -0500, noah_mendelsohn@us.ibm.com wrote:
> Mark Baker writes:
> 
> >> Sweet, sweet irony. 8-)
> 
> Or maybe a good example of keeping it simple.  Nothing prevents anyone 
> from publishing a specification for a different/enhanced HTTP binding that 
> provides richer features and more complex MEPs, which I believe this use 
> case to be.  Basing core interop on simple request/response seems to me to 
> be a good 80/20 point, not an oversight.  I have no problem with someone 
> doing another binding aimed more at HTTP exploitation, if there's user 
> demand.  I do think there is a question about about how any 
> application-level response is modeled.  It's one thing to have an 
> acknowledged one-way transmission, which is what my naive understanding 
> says you get with a 202.  It's another to have the response delivered 
> through another connection, through addressing that has to be worked out, 
> etc.  The key thing that a request/response MEP gives you, IMO, is that 
> the response is implicitly addressed to the requester.  Usually there is 
> also some sharing of connection infrastructure, particularly in the case 
> of a short-lived request/response.  That's what we're modelling with the 
> existing HTTP binding and I think it's a good 80/20 point.
> 
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
> Mark Baker <distobj@acm.org>
> 11/12/2004 04:11 PM
> 
>  
>         To:     noah_mendelsohn@us.ibm.com
>         cc:     Hugo Haas <hugo@w3.org>, www-ws-desc@w3.org, xml-dist-app@w3.org
>         Subject:        Re: Seeking clarification about the use of the HTTP binding
> 
> 
> On Fri, Nov 12, 2004 at 02:47:01PM -0500, noah_mendelsohn@us.ibm.com 
> wrote:
> > Hmm.  So an interesting question is whether the HTTP binding ever sends 
> a 
> > 202.
> 
> Ah, good point.
> 
> It's unfortunate we (XMLP) chose to declare the state transition on
> "200" rather than "2xx", but IIRC, there was considerable debate about
> this point, as those promoting "protocol independence" feared that
> exposing too much of HTTP to the application was a bad idea.  Support
> for 2xx used to be there[1], but was removed and replaced by [2] as a
> result (IIRC).
> 
> Sweet, sweet irony. 8-)
> 
>  [1] http://www.w3.org/TR/2001/WD-soap12-part2-20011217/#NFDC
>  [2] http://www.w3.org/TR/2003/PR-soap12-part2-20030507/#httpoptionality
> 
> Mark.
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> 
> 
> 

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Friday, 12 November 2004 21:47:35 UTC