Re: Proposal on use of HTTP Versions

HTTP versioning is hop-by-hop, not end-to-end, so implementations must 
be able to accept both 1.0 and 1.1 message versions; there is absolutely 
no guarantee that messages received will be 1.1, even if both SOAP 
endpoints implement 1.1.

As such, this wording may be too strong. The binding includes features 
(like conneg) that are defined by 1.1, but that doesn't mean that they 
can't be transferred in messages identified as 1.0; this happens all the 
time. Since this is the case, why limit the potential population of 
SOAP-capable HTTP implementations? Off the top of my head, Squid, the 
most popular open source intermediary, and most likely the most 
widely-deployed intermediary period, only does HTTP/1.0.

<mnot:proposed>
The SOAP HTTP Binding presented here provides a binding of SOAP to HTTP.
This binding conforms to the SOAP Binding Framework (see [1] SOAP 
Protocol
Binding Framework) and uses abstract properties as a means of making 
certain
features defined by HTTP/1.1 [RFC2616] available.  This binding MAY be 
used
with versions of HTTP that are compatible with HTTP/1.1 (including 
HTTP/1.0
and future HTTP versions with the same major number).
</mnot:proposed>


On Thursday, May 2, 2002, at 03:57  PM, noah_mendelsohn@us.ibm.com wrote:

> On today's TBTF call, I took an action item to propose text clarifying 
> the
> intended use of our HTTP binding with various versions of HTTP.  Here 
> is a
> proposed replacement for the first paragraph of section 7.1:
>
> <original>
> The SOAP HTTP Binding presented here provides a binding of SOAP to HTTP.
> This binding conforms to the SOAP Binding Framework (see [1]SOAP 
> Protocol
> Binding Framework) and uses abstract properties as a descriptive tool 
> for
> defining the functionality of certain features.
> </original>
>
> <proposed>
> The SOAP HTTP Binding presented here provides a binding of SOAP to HTTP.
> This binding conforms to the SOAP Binding Framework (see [1]SOAP 
> Protocol
> Binding Framework) and uses abstract properties as a descriptive tool 
> for
> defining the functionality of certain features.  This bind SHOULD be
> deployed using HTTP Version 1.1 [ref to RFC 2068].  This binding MAY be
> used with future versions of HTTP that may be developed as backward
> compatible replacements for HTTP Version 1.1.  This binding does not
> normatively provide for the use of HTTP Version 1.0 [ref to RFC 1945].
> </proposed>
>
> Note: this is slightly less elaborate than what I had proposed on the 
> phone
> regarding the use of HTTP 1.0.  On the phone, I had suggested a note 
> that
> would go into some detail describing the subsets of the binding (e.g. no
> content negotiation) that could not normatively be used.  In drafting 
> this
> text, it seemed to me more straightforward to not devote a lot of 
> detail to
> behavior that is not formally part of the specification anyway.  If 
> anyone
> does feel we should be more explicit, then I would propose the 
> following:
>
> <alternateProposal>
> The SOAP HTTP Binding presented here provides a binding of SOAP to HTTP.
> This binding conforms to the SOAP Binding Framework (see [1]SOAP 
> Protocol
> Binding Framework) and uses abstract properties as a descriptive tool 
> for
> defining the functionality of certain features.  This bind SHOULD be
> deployed using HTTP Version 1.1 [ref to RFC 2068].  This binding MAY be
> used with future versions of HTTP that may be developed as backward
> compatible replacements for HTTP Version 1.1.  NOTE: Although this 
> binding
> does not normatively provide for the use of HTTP Version 1.0 [ref to RFC
> 1945], a useful subset of this binding is compatible with HTTP 1.0.  For
> example, requests and responses can generally be sent as described 
> herein,
> but HTTP 1.1 content negotiation is not possible.
> </alternateProposal>
>
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>
>
>
>
>
--
Mark Nottingham
http://www.mnot.net/

Received on Friday, 3 May 2002 00:45:54 UTC