RE: Protocol Bindings

To get interoperability, surely we need to define both the envelope
encapsulation *AND* how it gets exchanged over an application protocol.

There may be many (M) encapsulations (text, binary, multi-part) and there
may be many (N) application protocols (BEEP, HTTP, Custom over TCP) and it
is better to define each just once, so rather than M*N definitions, we have
M+N definitions.

If you want to send me a SOAP envelope, it is no good us agreeing on the
layout of the octets if we can't agree on how to decide where one message
stops and the next begins (framing).  This, and a number of other services,
are provided by an application protocol.

We can argue whether BEEP or HTTP or whatever is better as an application
protocol, but the general services they provide are needed - and some piece
of functionality must provide them. Hence I think the diagram at:
http://www.w3.org/2000/xp/Group/1/04/23/XMLProtocolAbstractModel.html#Sec5.1
.1
is wrong.

The TCP column (left-most column) is completely missing an application
protocol. TCP is not providing you with framing (etc.) - so which component
is? There should be a small box in that column identifying this component,
with a name such as "custom". Both you and I might be able to handle TCP
connections and might be able to understand SOAP XML 1.0 envelopes - but
that still does mean we can communicate - we also need to agree the details
in the middle - how the encoding is carried in the transport.


Eamon

P.S. Check out the paper "On the Design of Application Protocols"
(http://www.ietf.org/internet-drafts/draft-mrose-beep-design-03.txt)

Received on Thursday, 5 July 2001 06:03:43 UTC