Tag Order

, ,
1

Imported from previous forum

2

[ original email was from Josh Hoffberg - j.hoffberg@gmail.com ]
Have any of you ever heard about Tag 96(Password) having to come immediately after tag 95(RawDataLength)during the logon message (35=A) or you will get a reject?

Thanks

3

[ original email was from Steve Wilkinson - steve.wilkinson@solutionforge.com ]
> Have any of you ever heard about Tag 96(Password) having to come

immediately after tag 95(RawDataLength)during the logon message (35=A)
or you will get a reject?

Thanks

Josh,

Strictly speaking, Tag 96 is RawData, having a data type of “data” (aka binary). In some systems, this tag is used to include a password in the logon message, hence the name confusion. As the field is of type “data”, the rules of FIX state that ALL such fields must be preceded by a length field (in this case, Tag 95, RawDataLength). If the length field does not precede the data field, then it is possible that the FIX message is not parsable (because the data field may contain an embedded SOH). Hence, the right thing for a FIX engine to do is to reject any message that fails to include the length tag immediately before the “data” tag.

Trust this helps.

Steve.

4

[ original email was from Jeremy Sutton - jezza.sutton@patsystems.com ]
Where RawData is required (due to counter-party negotiation) it should be preceded by RawDataLength for the reasons previously stated. It is not uncommon to find untrusted FIX connections using this pair for a password during logon (indeed, we do exactly this with our FIX gateway).