Re: TBTF: A small Doodle of an HTTP Binding

I like the general direction signaled by the combination of Mountain's 
original summary of our small group meeting [1] and Stuart's model for the 
HTTP binding [2].  I would change some of the structure and formalism a 
bit (see below), but reading between the lines I think we are on the right 
track.  Here are a few specific suggestions (that are also a very partial 
response to Henrik's note [3].  Henrik's note deserves a more careful 
response, which I will try to get to before the call.) 

Let me clarify how I would suggest we use certain terminology, at least 
for purposes of this e-mail thread (we can fine-tune the terminology as we 
write the actual specification): 

Module:  a specification for an optional function not included in the core SOAP 
specification.  Examples include security of various sorts, transactions, 
but also conceivably facilities that make sense only on one or another 
particular transport (e.g. there might be an extension to let you choose 
GET vs. POST or REQUEST for HTTP...that wouldn't make much sense on MQ). 
(Note:  I am intentionally not distinguishing modules which are specified 
in terms of a fixed set of "headers" vs. those that might have other 
properties outside the envelope...in my view, the same tools and 
abstractions (such as the ability to define properties) are available to 
those who write specifications for modules as we have in defining core 
SOAP features.)

Binding specifications vs. binding implementations:  I believe we can all agree to distinguish the two.   An HTTP binding 
specifications says: "here is how we will represent a one-hop request on 
the wire using HTTP".  A particular binding implementation is a piece of 
code which one can, in principle, test for conformance with that 
specification.  So, there might be an implementation for Windows and 
another for UNIX. I will try to use the two terms carefully below.

Feature interface specifications:  for each core feature of SOAP, and for each module, there is an 
interface specification.  The specification consists of the set of named 
properties used to model data, and a set of rules that implement the logic 
of the feature.  These rules can provide for checking and update of data 
found in the properties, for constructing and transmitting SOAP messages 
from data found in the properties, or for updating properties based on 
information received from a SOAP message.

Properties:  Properties model the data used to specify a SOAP core feature or 
module. 

Note: I have a concern with Henrik's suggestion that "A binding [binding 
specification?...NRM] may define a set of properties." [4]  In my opinion, 
the properties are defined by our specification (for core functions) and 
by the specifications for various modules (e.g. security) and message 
patterns.  This is a very fundamental distinction.  Particular binding 
specifications undertake to meet the contract(s) implied by the core and 
module specifications.   In other words, they agree to support those sets 
of properties along with the logic mandated for their use.   Reason:  the 
whole point of our framework is to show how multiple binding 
specifications can be developed to meet the same interface.  For example, 
we hope that both HTTP and MQ bindings can achieve request/response 
semantics that are similar enough that the applications can view the two 
transparently.  It is the common set of data at the input and output 
interfaces that are modeled as properties.  Therefore, the set of 
properties and the required logic associated with them are a contract 
which each binding specification (and thus each implementation of such 
specification) must implement.

Now, to be fair, it is perfectly reasonable to have individual 
extensions/modules which are binding-specification specific.  For example, 
if we decided to let the application have direct control over the 
SOAPAction http header, there would be nothing wrong with introducing a 
particular binding-specific property:

        httpbinding.SOAPAction="...."

I think it would be a big mistake to conclude that, in general, properties 
are defined by binding specifications.  I think it is a special case of 
the rule that "properties are (the data part of) the interface 
specification for core SOAP functions and extensions (modules?  what's our 
temr

Binding specifications and binding implementations: I like the start that Stewart has made [2], but I have a suggestion for 
making it more rigorous.  I think we need to split those aspects of the 
specification that are common across binding specifications, from those 
that are HTTP-specific.  So, there should be a specification for 
request/response in general that says something along the lines of: "There 
is a property called 'mep.isRequestorResponse".  If the message to be sent 
is marked "Response" then the binding specification must...{rules go here 
for what the binding must do in sending a response.  Presumably this would 
include rules along the lines of:  'attempt to deliver the response 
envelope to the SOAP note that sent the original request'}"

With that as a base, the HTTP binding specification in particular can say: 
 when HTTP REQUEST messages are received, the connection back to the 
requester must be kept open.  This specification meets the need for 
addressing responses by sending them over that open connection.  (An MQ 
implementation might do this differently, but the application would see a 
common service.)

Thus, each part of the specification is layered into a contract definition 
that comes from either core SOAP or the module, and a means of 
implementing that contract provided in each binding specification.

I have written this in some haste in the hopes that at least one or two 
readers may get to it before the call.  Also, as some of you know, I do 
use speech recognition software when writing long notes.  That tends to 
result in particularly laughable "typos" which I try to catch with careful 
proofreading .  When I am rushing as I am now, mistakes tend to get 
through.  Apologies in advance if I have missed any.

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0093.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0157.html 
(earlier W3C member-only copy at http://lists.w3.org/Archives/Member/w3c-archive/2001Aug/0063.html)
[3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0139.html
[4] 
http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/att-0139/01-binding_framework.htm

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------