Re: Proposal for a protocol binding model

Why is a separate property necessary? I'd imagine that you'd just
define two bindings; one without many (or any) properties exposed,
one with a number. You could use different content types for them
(tho I don't really see the utility in this).


On Tue, Aug 21, 2001 at 01:03:19AM -0400, Mark Baker wrote:
> Henrik,
> I like and support what you propose here, and while mostly complete,
> I believe it to be missing one important feature.
> As I discussed in my proposal for two HTTP bindings[1], I suggest that
> we need a means for unambiguously identifying when a protocol (including
> RPC) is being tunneled over an application protocol, versus when it
> inherits the application semantics of that protocol.  The binding model
> seems like the right place to specify this.
> Obviously it can't specify the syntax because that will have to vary
> depending upon the application protocol.  But it should mandate (or
> otherwise facilitate, should the model itself not be normative) that
> syntax be consistent for each protocol, not just each binding.  e.g.
> HTTP bindings may choose to use application/soap+tunnel+xml versus
> application/soap+xml (which, coincidentally, I am suggesting we use
> for our HTTP bindings).
> FWIW, this could be represented as a "property" per your proposal (say,
> "IS_TUNNELING"), and should be defined by us at a namespace.
> But the important part is somehow ensuring consistency of syntax for
> any given application protocol.
>  [1]
> MB

Mark Nottingham

Received on Tuesday, 21 August 2001 13:44:08 UTC