[standards-jig] JNG Ramblings.

Nathaniel Borenstein nsb at guppylake.com
Sun Aug 11 19:47:00 UTC 2002


As a Jabber newbie, I've just been lurking on this list, but I can't
resist joining the discussion about Mike's ideas, and especially the
issue of a binary protocol on the wire.

> When you combine the wire protocol and the manifest, you get something 
> that does basically the same thing as MIME.  Yes, that's true. But 
> it would be very messy to use MIME for wire protocol framing 
> because of its loose textual nature. 

This repeats a common misconception about MIME, which is that it is
*inherently* textual.  That is certainly the way it is generally used,
but it is not *necessary* to use it that way.  In particular, MIME was
designed to support binary transport optionally, even for multipart
messages.  The key is the separation of "Content-Type" from
"Content-Transfer-Encoding" (C-T-E).  If you have a binary-capable
transport -- which email definitely was NOT when MIME was designed, and
still isn't, really -- then you can simply throw away the C-T-E (and
base64) and still use MIME just fine.  

The only tricky bit is that when using a multipart, you have to be
careful that your boundary doesn't appear in the body of any of the
objects being encapsulated.  (This is easier for base64-encoded data,
because you can include in your boundary a character that isn't in the
base64 alphabet.)  But you could even eliminate that problem by
modifying MIME to add a "Content-Size" header.  That was much-discussed
during the MIME design, but it ultimately was rejected as being
incoherent for non-binary data over SMTP.  It should be fine for true
binary data in a binary protocol, as long as nobody is quietly
converting the data (say, between differing newline conventions) along
the way.  

> Besides, I think MIME is really heinous.

If you think that MIME requires C-T-E's and 7-bit transport, I can
certainly understand why you'd view it that way.  But if you eliminate
that problem, I think it is rather less heinous in this case than having
a maximum of 128 choices for the "Type" field and therefore an inherent
need for a content-type mechanism underneath it.

On the larger issue of whether a protocol such as Jabber's should be
binary or textual, you might be surprised to hear the author of MIME
coming down on the side of a binary protocol, but that's exactly what
I'm doing, primarily for the reasons given by Richard Dobson in his
message.  We did not design MIME as a textual protocol for ease of
developing/debugging.  We designed it that way because of the
constraints of real-world SMTP implementations that simply couldn't
handle 8-bit or binary data.  I don't *think* Jabber should have to deal
with similar constraints, although this may be an area where my
newbie-hood is showing.  And while I sympathize with the folks who want
to telnet directly, I don't think it would be very hard to write a
telnet gateway that makes it easy to type (almost) directly to the
server from a textual interface, and that's a small price to pay for a
33% speedup on big binary objects.  (Alternately, we could use an
approach like ESMTP which makes binary transport optional, and this
could be nearly always used by software but rarely or never by people
connecting with telnet.)

Unless there is a big need for backward compatibility with
non-binary-capable software, I would strongly support at least a binary
*option* in the protocol.  -- Nathaniel
----
http://guppylake.com/~nsb
----



More information about the Standards mailing list