The Global Technical Committee has reviewed and preliminarily approved the CME Market Data Extension Gap Analysis. This proposal addresses enhancements needed to support market data types for changing market needs and new products’ data attributes.
The document now enters a public comment period in which public review and feedback is encouraged. Once the public comment period closes, the Global Technical Governance Board will meet to review public comments before final approval.
Please post feedback, comments, and questions as replies to this discussion thread.
A link to the proposal can be found at: https://www.fixtrading.org/packages/fix-protocol-gap-analysis-cme-market-data-extension/
The public comment period ends on June 7, 2021.
Business Requirements
Page 7: is there a reason why the new values for 269 should be g, h, i and t instead of continuing with b (the next free value for tag 269, with all other existing values ascending)? Do I understand correctly that these values were chosen “due to existing system implementations”?
I don’t know how many existing system implementations of this already exist but in my opinion the priority should be to make this somewhat consistent with the already existing standard values for that field.
CME market data Implementation for price limits and price banding
Pages 8, 9: is there a reason why disabling these limits needs to send null for fields 1148, 1149? Can’t the fields just be omitted in that case? These are no required fields after all.
If not, null feels like a bad choice for a field of type Price or float respectively. (But 0 is probably also a bad choice since it could be a valid price.) Would some kind of boolean flag be helpful in that case that conveys that limits have been disabled?
Thank you,
Chris.
Hi Chris,
FIXmate shows 269 values c. d. e are already taken, and g, h, i are the next available. t= TWAP have been chosen, as you said, due to “existing system implementation”, we hope this is ok.
Regarding your second question why in CME example we are using 1148=null. Since CME market data is SBE encoded, a single SBE template contains all three fields for high, low limits and band differential that are independently updatable, this is one way to represent there are no longer standing limits for the contract, while band value may sill be in place.
The more traditional FIX way would be to use tag 279=2 MDUpdateAction=Delete and resend previous limits. For SBE implementations it makes more sense to send 279=0 MDUpdateAction=new and null values in tags 1148, 1149 or 1143.
Actually, value f is the next available one. 
The GTC normally follows the rule of taking the next available number or character(s) in the alphabet. We assess requests for specific characters on a case-by-case basis. Obviously we encourage users to come forward with a Gap Analysis before finalizing their roll-out and implementation. We do understand that it is very hard for an exchange to alter values once they have been implemented by their membership.
The “gaps” in the sequence of values are not pretty but should not be a real problem either. We also have gaps due to deprecated values, albeit we avoid to re-use any of them as they may still be used (deprecated does not mean deleted).
This is not correct: b=“Market bid”. You may have been looking at FIX 5.0 SP2 which included EP97 as last Extension Pack of SP1. Values b and c were added thereafter with EP106, followed by d with EP123 and e with EP190.
Hi @rfrenkel and @hanno.klein,
you are totally correct about the values for 269. Indeed I was looking at the legacy Fiximate, sorry. 
Regarding SBE: I only have basic knowledge about that but I think your proposal makes sense.
I was probably looking at this from the wrong angle. So the gap analysis introduces new fields or values but how this is implemented is another story and up to the implementor, correct?
Thanks,
Chris.
No worries, @christophjohn .
Correct, we are introducing few new 269 enumerations and proposing to add tag 1143 to PriceLimits.
Message examples in the proposal are based on CME implementation with SBE encoding in place. However, we don’t insist on this exact implementation and provided few sample messages just to illustrate the functionality and the FIX gap.
Well, not quite. The various FIX encodings differ in their syntax (aka wire format) but we would expect an SBE encoding to use char for MDEntryType(269) and ‘g’, ‘h’, ‘I’, ‘t’ on the wire. For SBE this takes up a single byte (meta-data is not on the wire) whereas tagvalue requires 5 bytes (269=g) and FIXML requires 7 bytes (Typ=“g”).
In my view the most value in the standard is in the meaning of those codes. The simple case is to use the same character values in SBE as in tagvalue encoding, but SBE supports further syntactical optimizations. For example, several boolean states could be combined into one bitset, very small on the wire.
Yes, that was clear to me.
I was more referring to the SBE examples from the GA where a field’s value is sent as null which would not make any sense in tagvalue (especially for a price field). So if anyone wanted to implement this functionality in tagvalue one would need to come up with a different solution.
BTW, sorry for hijacking this thread for my only loosely related question.
Thanks,
Chris.