Imported from previous forum
Observation :
The FIX 4.2 format apparently places no restrictions on the length of field for either UserDefined fields or the text field Tag#58. And there is a note in the field definition table for tag #58 that states there is no specified maximum for this tag#.
Question :
Are there any known practical restrictions to the maximum length of these or any other FIX fields, or rather was there a conscious effort to put no limitations on the length or content of these fields in keeping with the open architecture of the FIX protocol?
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Are there any known practical restrictions to the maximum length of these or any other FIX fields, or rather was there a conscious effort to put no limitations on the length or content of these fields in keeping with the open architecture of the FIX protocol?
You’ve hit the nail on the head. Fields purposefully do not have maximum lengths because doing so would be imposing on people how they need to run their business. Lengths of critical fields, like ClOrdID, OrderID, and ExecID need to be agreed upon bilaterally between counterparties.
Just try to pick a number for the maximum length of a ClOrdID and you’ll see the problem. Pick a number too low and a whole lot of firms will be up at arms because they need to embed more information into their ClOrdID than this allows. Pick a number too high and a whole lot of firms will be up at arms because they have to add significant bloat to their databases in order to remain compliant. I doubt you could arrive at a number that makes everyone happy.
In general, a good rule of thumb is that when sending such IDs, try to keep them as small as possible while still embedding necessary information (and possibly make an even smaller mode for handling systems with very narrow tables) and when receiving them, try to make your database wide enough to accomodate any reasonable (and some unreasonable) lengths without causing too much bloat.