- From: Chris Newman <chris@innosoft.com>
- Date: Fri, 19 Feb 1999 19:18:50 -0800 (PST)
- To: Josh Cohen <joshco@microsoft.com>
- Cc: jg@pa.dec.com, discuss@apps.ietf.org
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