Re: draft-ietf-impp-cpim-msgfmt syntax

Adam,

Monday, November 11, 2002, 3:36:55 PM, you wrote:
>> If a message is small, the percentage of "waste" is quite high.
>> But because the message is small, it doesn't matter.
>>
>> If a message is large, the bulk of the space is the content,
>> not the headers.  So, the inefficiencies of the header syntax
>> won't matter.

Adam>Intutively, it seems obvious that you
Adam> can't have it both ways.

It's not "both ways". The point was that a high percentage does not hurt
much when the total size is small. It is a bit like the problem of spending
too much time optimizing code that is rarely executed. Focus on what really
hurts, not just what is mathematically interesting.

Let's try it with some numbers:

Let's say a small message is a kilobyte with RFC2822 syntax and 2 kilobytes
with an XML syntax. That's 100% extra overhead. The only problem is that 2
kilobytes is still small enough to not matter.


Adam> While the wireless
Adam> carriers are taking the remarkable step of embracing IETF
Adam> protocols, there is a constant tension with the space inefficency
Adam> that many such protocols introduce.

In that case, my comment about the earlier concerns with RFC733/822 syntax
hold. If the communications channel is seriously bandwidth constrained, none
of these approaches is really acceptable. Apps protocols are typically
designed with a focus on things other than optimally efficient encoding.
Otherwise we would not have a textual syntax and otherwise be wasting so
many bits. (7-bit ascii in an eight-bit field is really stupid, if you are
worried about wasting bits. It is even more stupid when you don't use all 7
bits very much.)

The right answer is to do something binary that is much, much more bit
efficient. My guess is that the easiest way to achieve that, and retain
compatibility with the rest of the net, is to use a data compression
technique optimized for working on text, rather than do gateway translation
to a different syntax.

Given the high redundancy in the xml encoding, the effects of compression
should be quite nice.

For that matter, I suspect the encoding approach that Van Jacobsen used with
TCP header prediction would be worth exploring. The results can be
impressive.

d/
-- 
 Dave Crocker  <mailto:[email protected]>
 TribalWise <http://www.tribalwise.com>
 t +1.408.246.8253; f +1.408.850.1850




  [reminder: [email protected] for non-technical discussions, please]