RE: Use of TELNET for testing protocols

On Wed, 17 Feb 1999, Josh Cohen wrote:
> > Jim Gettys said this:
> > > Text protocols and telnet debugging have a lower entry cost, but much 
> > > higher curve as things get compicated.  Binary protocols tend to have 
> > > higher up-front costs (building a bit more infrastructure up front), but 
> > > lower difficultly curves, as the complexity of the protocol goes up.
> >
> definitely an insightful statement.
> 
> However, has IMAP or POP had the same problems because its text?
> Or, is it just HTTP's loose syntax of optional and ignored stuff
> that has cause so much pain?
> I havent noticed the same terrible cries in the IMAP/POP world,
> but then again, maybe I dont spend enough time in that world
> to notice.  Chris ?

POP is very simple, so it's a huge win that it's text.

IMAP is a more interesting case as it has a number of complex
datastructures which use a simple S-expression style syntax.  I don't know
of any significant problems that have been caused by these being text
encoded.

There are certain traditions which can make text protocols painful as they
get complicated.  For example, some people misinterpret the "be liberal in
what you accept" principle as meaning "accept illegal protocol".
Thankfully most of the IMAP server implementors didn't make this mistake
so the IMAP protocol is one of the most syntacticly interoperable text
protocols.

It does become harder to precisely specify a text protocol as it becomes
more complex.  But this may be a good thing as it makes an out-of-control
protocol designer suffer in a way that ASN.1 doesn't.

I have a definite preference for text protocols.  I've found them much
easier to write code for and maintain in practice than binary protocols. 
A key advantage text protocols have is that when there's an
interoperability problem, it is easy to prove to the customer who is at
fault since you can show them the actual protocol.  Sometimes the customer
even identifies who is at fault themselves.  Furthermore, a text protocol
trace looks the same regardless of who generates it.  Binary protocol
debugging info appears in whatever format was the implementor's whim if
it's available at all.

However, the relative advantages and disadvantages between text and binary
protocol encodings are negligible compared to other protocol design
issues.  Protocol simplicity and avoiding rarely-used features are _far_
more important.  I'd much rather implement and maintain a simple
well-designed binary protocol (e.g., Secure Shell 2) than a complex text
protocol (e.g., HTTP 1.1).

I should also point out the option of a hybrid encoding.  Use a simple
binary structure with fixed-length ASCII character strings for protocol
keywords.  You get all the advantages of binary encoding, and a protocol
dump is at least partially useful.  Secure Shell 2 has a different
interesting hybrid characteristic -- it uses length-counted text strings
for extensibility-oriented feature lists.

		- Chris

Received on Friday, 19 February 1999 22:19:44 UTC