Re: Proposal on use of HTTP Versions

OK.  FYI, I was merely reflecting the will of the TBTF, which had decided 
(for better or worse) to de-emphasize HTTP 1.0.  We had informal reports 
that deployment of HTTP 1.1 was nearly ubiquitious, and you are reporting 
information to the contrary.  In any case, I have no strong personal 
opinion, was just trying to set down what the TBTF decided.   How about:

<noah:revisionOfMnotProposed>
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
representing the state at each endpoint.   Certain optional features of 
this binding depend on capabilities provided by HTTP Version 1.1 (for 
example, this binding allows for content negotion.)  Implementations of 
this binding SHOULD use HTTP 1.1 [RFC 2616] (or later compatible versions 
that share the same version number.)  Implementations of this binding MAY 
be deployed using HTTP Version 1.0 (though certain optional features of 
the binding may be unuseable in this case.)  Furthermore, implementations 
SHOULD account for the fact that HTTP 1.0 intermediaries MAY alter the 
representation of messages, even in situations where the endpoints use 
HTTP 1.1.
</noah:revisionOfMnotProposed>

Does that capture the spirit of where you'd like to go with this?  I don't 
think we're using abstract properties to describe just HTTP features.  We 
also use them to manage SOAP MEPs, SOAP envelope infosets, etc.


------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Mark Nottingham <mnot@mnot.net>
05/03/02 12:45 AM

 
        To:     noah_mendelsohn@us.ibm.com
        cc:     xml-dist-app@w3.org
        Subject:        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 09:57:27 UTC