Recently had an issue rendering FIX logs in our log reader utility with FIX messages sent by one of our partners. The culprit appeared to be an extra space and carriage return in one of their error messages. When I raised this with the vendor they pointed out that it was actually an invisible character linefeed. Are these allowed in FIX messages? Looking through the 4.2 spec I only see the SOH delimiter allowed.
We send comment payloads from our OMS to EMS systems in tag 58 and include CR and LF if present. They are both ASCII (013 and 010) and are therefore valid in fields marked as String in the spec.
See the FIX data types section of the spec for details of what’s valid where.
Hope this helps
Sorry, but I think the part about these being valid in String fields is not true. Please see here: https://www.fixtrading.org/standards/tagvalue-online/#lexical-space
That table says for the String data type:
Alphanumeric free-format strings can include any character except control characters.
All ASCII codes below 32 are actually control characters.
Maybe you mixed this up with “data” fields which can include also control characters, even SOH.
Hope that helps.
Cheers,
Chris.
Thanks Chris. My FIX log reader would agree with you.
Thanks again.
Matt
Good info Chris
But the OP stated FIX.4.2 and the original spec document (not the online spec) which I have downloaded states that SoH is the only disallowed char in a string field in that version.
Would be interesting to find out when that changed as many systems out there were written prior to the online spec being available.
Two things:
-
I always was under the impression that things like data types and other session-level specific stuff (e.g. session-level test cases) were corrected/refined/amended in later versions (or Errata of that version) and should be adopted for the prior versions also. But maybe I got this wrong and a FIX expert could clarify this further.
I agree that there might be some old systems handling this otherwise but we are in 2021 and unless that FIX4.2 system was developed 2001 and not changed since then there should be no reason to follow rules that were since been refined. -
My FIX 4.2 spec (downloaded from https://www.fixtrading.org/standards/fix-4-2/, version from 20010501) says:
Alpha-numeric free format strings, can include any character or punctuation except the delimiter.
So “alpha-numeric” actually narrows it down to just letters and numbers, “punctuation” adds things like dots, commas and so on. So no word of control characters actually.
Cheers,
Chris.
Edit w.r.t. point 1: there also is a note on https://www.fixtrading.org/standards/fix-4-2/ stating:
Implementers of FIX version 4.2 should base their implementations on this errata release, referring to the FIX 4.2 Specification document with Errata 20010501 to ensure the most consistent implementation and clearest understanding of the FIX protocol.
You are correct. On top of that, the FIX Tag=Value encoding has been refactored into a standalone spec as part of last year’s submission of the refactored FIX Session Layer to ISO. See the GTC blog for details. That answers the question from @dominicgifford on when that “change” happened.
The online spec is only provided for FIX Latest and intentionally does not include anything about the encoding. Legacy FIX versions like FIX 4.2 are only available for download. They do include the tag=value encoding but we recommend to use the standalone spec that tried to remove ambiguities, especially in terms of the datatypes as mentioned by @christophjohn in one of his posts above.
Last not least a general note on text fields. These fields should always be a single line from a semantic point of view. If the semantic requires multiple lines then the message would contain a repeating group of text fields. The repeating group LinesOfTextGrp is the example for this and it is used in Email(35=C) and News(35=B) messages. Also, CR/LF can be tricky is you need them to work on both Windows and Unix systems. So my advice would be to avoid them wherever you can and use other means to achieve the desired effect.