Imported from previous forum
We are party to the communication between two FIX engines. However the SELL side and the BUY side differ in thier interpretation of a statement in the paragraph headed by “FIX Message Format and Delivery.” The statement is:
"Except where noted, fields within a message can be defined in any sequence(Relative position of a field within a message is inconsequential.) The
exception to this rule are…"
The SELL side interpretation:
After tags 8, 9, and 35, body and header tags can be intermixed (appear in any sequence); tag 10 must be the last tag.
The BUY side interpretation:
After tags 8, 9, and 35, header tags can appear in any order, but all header tags must appear before any body tags. Body tags can appear in any order; tag 10 must be the last tag.
As an example take the Logon message. Must tag 98 [EncryptMethod] be positioned after the last header tag, or as long as it comes after tag 35 the message is considered as having been properly formatted.
Avner Gelb
SIAC
Thank you for your assistance.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
The buy side interpretation is correct for FIX 4.2. All header fields must come before all body fields, which must come before all trailer fields.
FIX 4.2 is the first version to make this requirement explicit, however one could infer this requirement from previous versions of the FIX spec. Hence I strongly recommend anyone wanting maximum interoperability place fields in header, body, trailer order regardless of the FIX version number.
While it is true that the messages should come in the form Header fields, Body Fields, Trailer fields, it is not a good idea to make an application that relies on this. The good thing about the tag value protocol is that it should not matter where the tags come in the message with the exception of the the start three tags and the final tag. Making an application which relies on more than those four fields being in any particular location does not seem like a good idea or a good way to deal with any tag value messages, including FIX.
> While it is true that the messages should come in the form Header fields, Body Fields, Trailer fields, it is not a good idea to make an application that relies on this. The good thing about the tag value protocol is that it should not matter where the tags come in the message with the exception of the the start three tags and the final tag. Making an application which relies on more than those four fields being in any particular location does not seem like a good idea or a good way to deal with any tag value messages, including FIX.
>
I understand your point in this post but relying upon tag order is necesary when dealing with repeating groups when not employing repeating group end tags or terminators. Perhaps this has become more evident with 4.2 than with previous versions.
Colin Clark
IBSN, Inc.
www.ibsncentral.com
The 4.2 spec is clear regarding order of Header, Body, and Trailer.
From a programming standpoint, I would suggest one coding one’s message construction in spec order and coding one’s message parsing to be as order-insensitive as possible.
Note also that as we all start using XML more, XML "DTD validation" is order-specific
> While it is true that the messages should come in the form Header fields, Body Fields, Trailer fields, it is not a good idea to make an application that relies on this. The good thing about the tag value protocol is that it should not matter where the tags come in the message with the exception of the the start three tags and the final tag. Making an application which relies on more than those four fields being in any particular location does not seem like a good idea or a good way to deal with any tag value messages, including FIX.
>
[ original email was from Ian Orford - ian.orford@dresdnerkb.com ]
I suspect I can guess which engine has a problem with messages that are not in header-body-trailer tag groupings because we have the same problem with our engine.
I would argue strongly that FIX sessions prior to version 4.2 are legal in this respect as long as tags 8, 9, 35 and 10 are 1st, 2nd, 3rd and last respectively. I think it is invalid for engines to force the new FIX 4.2 rule onto older sessions.
We have to interface to a lot of engines using FIX 4.0 who tend to put tag 34 immediately before tag 10.
Until our vendor sorts the problem out, we run these sessions through a pipe process that rearranges the tags into an order that our engine likes.
Regards,
Ian Orford.
Note that "The general format of a FIX message is a standard header followed by the message body fields and terminated with a standard trailer." statement has existed in the spec for FIX 3.0, 4.0, and 4.1.
Also note that the FIX 4.1 Errata 19990630 added ", and general message format of standard header followed by body followed by standard trailer" as one of the explicit exceptions to "in any sequence". These are all in "Message Format" within "FIX MESSAGE FORMAT AND DELIVERY". FIX 4.2 simply made the stated exceptions in FIX 4.1 Errata a bulleted list.
> I suspect I can guess which engine has a problem with messages that are not in header-body-trailer tag groupings because we have the same problem with our engine.
>
> I would argue strongly that FIX sessions prior to version 4.2 are legal in this respect as long as tags 8, 9, 35 and 10 are 1st, 2nd, 3rd and last respectively. I think it is invalid for engines to force the new FIX 4.2 rule onto older sessions.
>
> We have to interface to a lot of engines using FIX 4.0 who tend to put tag 34 immediately before tag 10.
>
> Until our vendor sorts the problem out, we run these sessions through a pipe process that rearranges the tags into an order that our engine likes.
>
> Regards,
> Ian Orford.
>
[ original email was from Ian Orford - ian.orford@dresdnerkb.com ]
> Note that "The general format of a FIX message is a standard header followed by the message body fields and terminated with a standard trailer." statement has existed in the spec for FIX 3.0, 4.0, and 4.1.
Indeed, but the following statement "Except where noted, fields within a message can be defined in any sequence (i.e. relative position of a field within a record is inconsequential)" undoes all the good work of the first.
Clearly its an ambiguity, hence the later clarification. As Scott suggested in other posts, its up to engines (especially expensive ones!) to be as flexible as possible to help reduce problems.