RE: Proposal for a protocol binding model

We could but bindings may not be nestable without tweaking and nested
bindings may not always expose all properties of the nested bindings. An
example of the former is the SOAP attachment binding that when used in
combination with the HTTP binding may force another media type simply
because MIME multipart/related has another media type than a plain SOAP
message. An example of the latter could be the RPC convention over SMTP
not exposing the SMTP property of sending a one-way message.

With a list comes also the need for a substantially more complicated
negotiation mechanism: I can do A,B,C but not A,C along with the notion
of figuring out which combinations are supported and what the exposed
set of properties are.

From a simplicity point of view, I would tend to say that knowing the
set of available combinations and how they behave is not nearly as
straight forward as knowing a list of URIs where somebody else has
described the relationship to other bindings.


>You consider a combination of bindings (e.g. SMTP+RPC) as a 
>new binding requiring a new identifier.
>Once people have come up with lots of different nested 
>bindings (attachments, RPC, maybe compression, etc), the 
>number of combinations will be fairly high, and a URI for each 
>of them might become unworkable.
>Presumably, the binding (and unbinding) of the SOAP message 
>will have to be an ordered operation: e.g. XML Infoset -> XML 
>serialization -> MIME multipart -> SMTP.
>What about an ordered list of URIs for a combination of bindings?

Received on Thursday, 16 August 2001 22:27:34 UTC