Re: Seeking clarification about the use of the HTTP binding

Mark Baker <[email protected]>
Newsgroups gmane.comp.web.services.description,gmane.text.xml.distributed
Message-ID <[email protected]>
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, [email protected] 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 <[email protected]>
> 11/12/2004 04:11 PM
> 
>  
>         To:     [email protected]
>         cc:     Hugo Haas <[email protected]>, [email protected], [email protected]
>         Subject:        Re: Seeking clarification about the use of the HTTP binding
> 
> 
> On Fri, Nov 12, 2004 at 02:47:01PM -0500, [email protected] 
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.