Proposal for a protocol binding model

One of the things that I think we as a group keep circling around is the
characteristic (for better or for worse) of SOAP that in effect it does
not define an application in the traditional sense of an application
layer protocol. It does not stand up and say: "I am a hypertext protocol
(HTTP)", or "I am a file protocol (FTP)", or "I am a mail protocol
(SMTP)". Rather, it says: "I am sort of a funny protocol that you can
use for a lot of things - likely including the applications above."

One way to approach this is to say something like this: SOAP doesn't
really define an application, but because we want to make a variety of
typical applications easy to support, we define a set of properties that
are typical of commonly used applications. In many ways this is
consistent with the definition of the RPC convention which I see as a
particular application - it defines certain behaviors, a particular
message exchange pattern, and has certain expected QoS behaviors.

I also believe that saying that such applications can be part of the
binding is a consistent way of approaching this. I tend to see the RPC
convention as effectively a binding and if we have a nested binding
model, one can nest the RPC binding with the SMTP binding. We can even
model SOAP attachments in the same way allowing one to nest the RPC
binding with the SOAP attachments binding with the SMTP binding, say.

However, it also seems feasible not to use a binding that implies some
sort of application but rather have the application be defined within
the SOAP message using the SOAP extensibility mechanism. This is for
example the case with the DIME binding. DIME doesn't define an
application but completely leaves this up to the SOAP layer.

I think we have to accommodate both models--if for nothing else then
because we have real examples of both types of bindings. The model
provided here is rather simple but I think it might allow for much of
what I think we have been talking about

Details on the model is in the attachment (slightly updated)

Henrik