RE: Request to fix use of "transport"

> "transport protocol" has a very precise meaning in networking, 
> and we are misusing it in the current drafts by characterizing 
> application protocols as transport protocols.  This can only lead 
> to confusion, and ultimately will only hurt interoperability ...

Agreed. The use of the term "transport protocol" within the specs is
just plain wrong and should be fixed. The possible substrates beneath
SOAP can provide a rich and diverse range of functionality, much more
than simply transporting the bits. We need terminology that reflects
that. Even those (I am not one of them) who advocate using the web
browsing protocol, HTTP, for SOAP will agree that the second 'T' in HTTP
means "transfer", not "transport". 

Other substrates, such as BEEP, support the idea of configurable
transport bindings - where the use of the term "transport" really means
transport (e.g. completely transparent to what is above it, BEEP could
have a transport binding to a single TCP socket, to SCTP, or even to
multiple TCP sockets [provided you look after congestion issues]).  To
talk about BEEP being a "transport" for SOAP and then to talk about BEEP
tranport bindings is messy. 

So, what terminology should SOAP use?

> s/transport binding/protocol binding/g
> s/underlying transport protocol/underlying protocol/g
> s/protocol for transport/protocol/g
> s/transported/sent/g (seems to cover both transport and transfer)
> s/transport message exchange/message exchange/g (I think we might have
>   agreed to this change already?)
> s/transport:/protocol:/g

These would seem fine to me. Two alternatives I could think of are
"substrate binding" or "transfer binding". 

Anyone else got other alternatives?

Eamon

Received on Wednesday, 6 March 2002 09:38:42 UTC