W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

Re: Binding example discussion

From: Mark Baker <distobj@acm.org>
Date: Wed, 18 Jul 2001 13:36:47 -0400
Message-Id: <200107181736.NAA09733@mail3.magma.ca>
To: Mark Nottingham <mnot@mnot.net>
CC: XML Distributed Applications List <xml-dist-app@w3.org>
7/17/2001 8:16:13 PM, Mark Nottingham <mnot@mnot.net> wrote:

>Hi Mark,

Hi Mark,

>On Tue, Jul 17, 2001 at 05:24:54PM -0400, Mark Baker wrote:
>> My comments;
>> "If a SOAP envelope is not to be conveyed in the HTTP request, the
>> request method used should be 'GET' (section 9.3)."
>> If SOAP isn't being used on the request, how do we know that GET
>> semantics is what is desired?  I suggest removing that point.
>Good point; the request method shouldn't be used to identify SOAP
>messages; the content-type should (which isn't yet in this document).

Yes, also a good point.

>> "If a SOAP envelope is to be conveyed in the HTTP response, it
>> should be the complete content of the message body, as defined by
>> RFC2616, section 6, with a '200 OK' status code (section 10.2.1)."
>> I've stated my position on this before, and will restate for
>> emphasis.  I believe it's dangerous to require only a 200 response
>> code, and would strongly recommend that my suggestions in [1] be
>> followed.  Can I ask for a pointer to where the decision to use
>> only 200 was made?
>Mark, this is only a rough expression of an HTTP binding, to give the
>group an idea of what I think a binding should look like; it isn't a
>definitive HTTP binding description. The focus is on the overall
>form, not the specific content.
>500 vs. 200 is a fight for another day ;) 

Phew!  Sorry, I misunderstood the intent of this brief.

>(That said, thanks for the reference; I hadn't seen that, and it
>makes some persuasive points)


>> "Additionally, implementations may make the following available:"
>> I'd also ask that the list of services be explicitly labelled as
>> non-exhaustive.  New HTTP based services will continue to be
>> defined over time.
>See my first message to Henrik. I'm concerned about the requirements
>that allowing an open-ended group of services will place on
>implementations. It may be fine, we should just think through it...

For sure.  But HTTP defines the model for these services for us, so as long as we don't do anything in the binding to 
adversely impact any existing feature of HTTP, we should be able to continue to deploy new HTTP based services
(for example, annotation proxies).  I'm really just talking about R803 here.

Received on Wednesday, 18 July 2001 13:36:48 UTC

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