Quote from j_medved:
What you are talking about is sending the high/low as LAST if they exist. The problem with that is that it will break the way ticks are interpreted by many programs. IB sends each field separately. If LAST is in affect overloaded, it would change how various fields would have to be grouped together into a single quote. For example, does the volume that is sent get assigned to the quote with the LAST=HIGH, LAST=LOW or just LAST?
As for sending the high/low as a delta, well, that may be over complicating things a bit
I think I jumped the gun when I said "no fields". I guess one extra field would be needed for each snapshot, so that each snapshot will have two prices: the first extreme to occur and the last extreme to occur. If the HI (LO) occurs first, then the HI (LO) will be transmitted as the first extreme, otherwise, the LO (HI) will be so transmitted.
So some changes would be needed in other software, but I think the changes would be worthwhile.
Volume would get assigned to the only price tick, when HI = LO, and gets assigned to the 2nd price tick when HI <> LO. The 2nd price tick is the one which occurs most recently. This would be just as accurate than the existing implementation.
Perhaps it would be possible to reduce bandwidth requirements by transmitting the 2nd price tick only when HI <> LO, and by setting an unused bit in some other field, to indicate whether or not each individual snapshot comes with a 2nd price tick. I don't know the formats actually used, so even if this is feasible, it might not produce significant savings.