Session level rejects and numeric data types

, ,
1

Imported from previous forum

2

According to the 4.4 spec (volume 2, page 29) in “When to send a Session Reject vs. when to ignore the message” there is a note referring to the Reject message description that says:

The receiving application should disregard 
any message that is (a) garbled, (b) cannot 
be parsed or (c) fails a data integrity check.

So we are supposed to discard garbled messages, but otherwise we should reject them.

Now, a garbled message is defined very clearly in 4 bullets (next section of specification):

  1. BeginString is valid and first tag
  2. BodyLength is second tag and has correct length (allows locating checksum)
  3. MsgType is third tag
  4. Checksum is last tag and has correct value

The way I read the note on when to reject, I think © is included in (a). I interpret the ‘fails a data integrity check’ to mean the checksum is wrong so that would make the message garbled as per point (4) which should then be ignored.

Therefore the only reason to send a reject is (b): cannot be parsed

What should we consider as impossible to parse? In this byte stream where 8,9,34 and 010 are all ok:

8=x|9=y|34=z|(data)010=chk|

…I would consider (data) to be invalid if:

  • We locate something where the tag is not a number (e.g. CHARS=123|)
  • We locate something where the value length is zero bytes, where SOH immediately follows the equals (e.g. 7=|)
  • We locate a tag in the end of (data) which is adjacent to the checksum (e.g …7=10|789010=chk| where 789 are digits that are adjacent to 010=chk| checksum in the end of the message
  • We locate something where the tag is an int but the value has non-digits (e.g. 7=5.3| or 7=abc|)
  • We locate something where the tag is an float but the value is not a number (e.g. 270=abc| or 270=-13.25.1|)

Is it ok for FIX implementation to reject messages that violate the above and not deliver them to the application?

Is there some list somewhere on the conditions where it’s ok to reject automatically?

The above list has what I consider to be ‘safe’ but I am particularly concerned about value-range validation. For instance, the types Length, NumInGroup, SeqNum, TagNum are not just integers, but they should be positive. I could reject automatically if I saw ‘34=-1|’ because a negative sequence is out-of-range based on the data type (must be positive). But then I posted earlier that the same holds for SeqNum, but we allow EndSeqNo in resend request messages to have the value zero (not positive) so an automatic reject in this case would prevent one from implementing the “resend from X till latest message” functionality.

Thanks,
Alex

P.S. In all of the above I use the vertical bar | for the SOH delimiter.