Re: TBTF: nature of transport bindings

Mark,

I tend to think that it will fall somewhere in the middle
(things usually do;-).

I certainly agree that some means of communicating/negotiating
features will be required in nearly all cases. In addition, it
is likely that each binding will require its own mechanism to do so.

The SOAP over BEEP binding [1] provides a 'features' attribute
to be used for this during channel start-up. In addition, it 
is given a specific BEEP profile name (a URI).

It would seem to me that what you describe as a "loose"
specification of a binding with some external characterization
(e.g. WSDL) mechanism employed to specify features used
isn't really a loose specification. It is left to others
to provide the requisite tightening.

Cheers,

Chris

[1] http://beepcore.org/beepcore/beep-soap.jsp

Mark Nottingham wrote:
> 
> As mentioned on the call today, I think one of the decisions we need
> to make in defining bindings is their scope.
> 
> I can identify two approaches:
> 
> * Bindings are expansive and exclusive - there is a 1:1 relationship
>   between bindings and what is bound to. E.g., there is an
>   authoritative 'HTTP' binding, and all SOAP messages sent across an
>   HTTP connection (as identified by URI scheme, port, protocol
>   header, etc.) are presumed to use it.
> 
>   This implies that use of protocol-specific features (e.g.,
>   authentication, correlation, status codes, etc.) is specified
>   externally (e.g., by WSDL), and that the transport binding is
>   'loose'.
> 
> * Bindings are specific and non-exclusive - there can be a number of
>   bindings for a particular transport, each with different features
>   (e.g., MEP, correlation, use of status codes, etc.). The nature of
>   the SOAP interaction over the binding is determined by the identity
>   of the binding.
> 
>   This implies that a means of communicating the identity of the
>   binding in use will be developed, and may engender a proliferation
>   of binding definitions. Bindings would be 'tight', and XMLP WG's
>   output would most likely be an HTTP binding optimised for RPC
>   (reflecting current use).
> 
> Both approaches seem to have their good and bad sides. I'd note that
> in either case, we seem to have a requirement to have a way to
> communicate the features in use; it's just a question of whether it's
> better to do this with a single token (option two) or with a set of
> metadata (option one).
> 
> These options can also be viewed as a continuum, or a grab bag (e.g.,
> an expansive-and-exclusive approach with tightly defined permissable
> status codes). I'd be interested to hear where people presently sit,
> if this is felt to be a useful way to frame the problem.
> 
> --
> Mark Nottingham
> http://www.mnot.net/