[standards-jig] JNG Ramblings.

Mike Lin mikelin at MIT.EDU
Wed Aug 14 13:22:26 UTC 2002


> For my part, I think that issue #2 is the critical one, and that as long
> as efficient transport of large objects is *possible*, there's probably
> no completely "right" answer to #1.  However, this leaves me rather
> strongly biased towards a textual protocol that resembles all the other
> successful Internet protocols.  I don't think the potential advantages
> of a general binary framing protocol are sufficient to outweigh the
> proven successes of primarily text-based protocols on the Internet.  

Well, I have to say I'm a bit confused by this seemingly pervasive
assumption that only (or mostly) text-based protocols have succeeded on
the Internet. I think we can find numerous examples of pervasive binary
protocols and formats, especially where performance matters. We could
imagine DNS, LDAP, and SOCKS very naturally involving text protocols,
but they're OK as binary. Others are things I don't imagine you would
really ever want to do with a text protocol, like TLS, DHCP, MPLS and
RTP.

I think it is arguable, in fact, that many of the transports on the
Internet that are most well-suited to handling arbitrary literal binary
data are in fact length-prefixed framing binary wire protocols. I know
there are some glaring exceptions like HTTP, but I don't count really
count disconnecting as a good way for us to handle framing.

I'll agree to the pretty obvious fact that most programmers and
standards-makers tend to want to shy away from binary protocols, but I
wonder how much of this is based on their technical disadvantages, and
how much of this is just a self-fulfilling prophecy.

> At the risk of sounding flippant, can you point to one truly elegant
> protocol that has succeeded on the Internet?  Elegance is often the
> enemy of practicality.

I think OpenPGP's structured packet format is very cool. (The problems
that need to be solved for processing huge globs of data are sometimes
similar to those faced by wire protocols.)

LDAP is nice too; the original LDAP spec was just 22 of those short RFC
pages! And 90% of the current protocol still comes across in about that
amount of text. The rest is annoyances like SASL and StartTLS and DER
encoding and that crap... :-)

BGP is interesting, although that's more about the cleverness of the
conceptual design than the wire protocol itself.

I think there may be some variance in what "elegance" is to different
people, and that's fine. For me, it's what is simplest to implement,
which I'm not sure should often be in conflict with practicality,
although that's tragically arguable :-(

> To paraphrase Mao, when I hear people talk about
> elegance in protocol design, I reach for my revolver....

I'm curious what you thought about MTR's (I found entertaining)
"elegance of an xml-based framing mechanism" then :-)

> Finally, I should say that I do in fact share some of Mike's frustration
> at the idea of not being able to efficiently handle asynchronous XML
> receipt in non-reentrant XML parsers.  Would it be totally outrageous to
> consider some kind of clear "end of document fragment" marker (coming
> *after* a completed XML fragment) that would allow the re-assemply of
> the complete XML document (before passing it off to the XML parser)
> without having to fully parse the XML?  -- Nathaniel

It would be better than what we have now, but when you see the "end of
document fragment" marker, you're just going to go calculate the
fragment length anyway. And I tend to think that anything but length
prefixing is kind of dangerous if we want to transport binary payloads.

6 months after writing it, I think JEP-0017 framing is dorky, but it
doesn't have encodable limitations and I'd prefer it over a byte
sentinel.

DW did bring up a good point (though I blew some steam off at him) that
it's not obvious that we can solve a lot of the asynchrony problems by
adding framing to the current protocol anyway, due to the fact that in
the current protocol, the entire session is a streaming document; so
even if you had the packet boundaries, you'd still need a reentrant XML
parser. You can hack it by parsing each packet as its own document, but
this is somewhat messy and it's "incorrect".

So I don't think it's obvious that the current protocol is fixable; in
any case, I hope this at least tells us that whatever we do, the
streaming document has gotta go.

Guys, if I sound offensive and bitter, it's because I've been trying to
get all this done for the past year :-(

-Mike




More information about the Standards mailing list