RE: TBTF: A small Doodle of an HTTP Binding


Thank you for clarifying your model although it has left me quite
concerned about the scope of our current enterprise. A few comments

* In your definition of "module" you mention that "(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 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.)".

Unless I am missing something I can't see how this can be true - we do
not in general have the same mechanisms available for describing
features *outside* the SOAP envelope as we do *inside* the envelope. For

1) we can't rely on a consistent naming model (in SOAP we have qnames of
the header entry)

2) we can't rely on any processing enforcement (in SOAP we have the
mustUnderstand attribute)

3) we can't rely on support for intermediaries (in SOAP we have the
actor attribute)

* I don't think we need the separation between binding specifications
and binding implementations. Given that we shied away from providing any
distinction between a SOAP "module" and a SOAP "handler" in the SOAP
spec terminology, I would encourage us not to attempt doing this within
the binding framework and rather focus on the implementation independent
aspects. For the purpose of defining a framework, where would we ever
want to differentiate between a binding running on Unix or Windows?

* You state that "Feature interface specifications:  for each core
feature of SOAP, and for each module, there is an interface
specification." but I am not sure where the notion of an interface comes
from in this context nor how it relates to our notion of blocks and SOAP

Given the current structure of SOAP, I think a more natural separation
of issues is the following

A) Features defined *within* the envelope follow the normal SOAP
processing rules and are generally referred to SOAP extensions or blocks

B) Features defined *below* the envelope may follow any processing rules
defined by the environment in which the features are defined. Features
are generally defined as "properties" and the environment is generally
defined as a "binding". Bindings may refer to properties in other
bindings and say that they support them in various ways and bindings may
be nested with other bindings in order to compose composite bindings.

In this model (which I described in some detail in [3]) there is no
notion of interfaces, implementations, or platform specific details. It
allows one to make bindings that are completely abstract and for other
bindings to refer to these abstract properties and it allows for
properties to be propagated through nested bindings.

This leaves us with a model that simply consists of bindings and
properties - whether you want to have abstract bindings with abstract
properties or very concrete bindings with concrete properties is
completely up to the author of the binding.

One of the nice properties of this model is that bindings can be
composed freely. For example, I can define a DIME binding for dealing
with binary attachments in the following manner:

* If I know about the SOAP attachment binding, I may want to reuse the
attachment property defined by that binding as it may cover what I need.
If not then I can define my own property that abstractly talks about
what it means to have an attachment. I could even define a binding with
only the abstract notion of an "attachment" and have the DIME use that
property in its binding.

* I can use the DIME binding directly over TCP which gives me a binding
with one set of properties

* I can use DIME over HTTP which gives me another binding with another
set of properties

* I can use DIME over SMTP which gives me yet another binding with some
third set of properties 

Are there any cases where this is not sufficient?

Henrik Frystyk Nielsen


-----Original Message-----
From: [] 
Sent: Friday, August 17, 2001 07:09
To: Williams, Stuart
Subject: 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

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 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 th! e 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: 


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. 

(earlier W3C member-only copy at 

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

Received on Monday, 20 August 2001 14:46:05 UTC