Imported from previous forum
In FIX_Transport_1.1.pdf page 38 of 66 (March 2008) defines a Garbled message as
[start quote]
BeginString (tag #8) is not the first tag in a message or is not of the format 8=FIXT.n.m.
BodyLength (tag #9) is not the second tag in a message or does not contain the correct byte count.
MsgType (tag #35) is not the third tag in a message.
Checksum (tag #10) is not the last tag or contains an incorrect value.
[End quote]
The following additions should be made to the above list of definitions of a garbled message
SenderCompID (tag #49) is not the fourth tag in a message.
TargetCompID (tag #56) is not the fifth tag in a message.
ApplVerID (tag #1128) if present in message is not the sixth tag in a message.
Non numeric Tag is present in the message, for example ^X=123^
(Request :- If this is not the correct forum for discussing FIX_Transport_1.1.pdf, please let me know the correct forum)
Regards,
K. Mahesh
Addition
Invalid Tag is present in message, examples
^0=ABC^
^-77=XYZ^
Tag 89 Signature if present should preceed checksum.
Tag 93 Signature length (required if Signature is present) must precced Signature
Mahesh, I don’t believe that we reached this consensus on FIXT.1.1 in terms of extending the tag order to SenderCompID, TargetCompID and ApplVerID. There was considerable push back.
In FIX_Transport_1.1.pdf page 38 of 66 (March 2008) defines a Garbled
message as[start quote]
BeginString (tag #8) is not the first tag in a message or is not of the
format 8=FIXT.n.m.BodyLength (tag #9) is not the second tag in a message or does not
contain the correct byte count.MsgType (tag #35) is not the third tag in a message.
Checksum (tag #10) is not the last tag or contains an incorrect value.
[End quote]
The following additions should be made to the above list of definitions
of a garbled messageSenderCompID (tag #49) is not the fourth tag in a message.
TargetCompID (tag #56) is not the fifth tag in a message.
ApplVerID (tag #1128) if present in message is not the sixth tag in
a message.Non numeric Tag is present in the message, for example ^X=123^
(Request :- If this is not the correct forum for discussing
FIX_Transport_1.1.pdf, please let me know the correct forum)Regards,
K. Mahesh
Jim,
I thought the order given in FIXT Header Mapping Table on Page 31 of 66 is correct. This was confirmed by Lisa Taikitsadaporn of Brook Path Partners at
http://fixprotocol.org/discuss/read/090515da
Regards,
K. Mahesh
Mahesh, I don’t believe that we reached this consensus on FIXT.1.1 in
terms of extending the tag order to SenderCompID, TargetCompID and
ApplVerID. There was considerable push back.In FIX_Transport_1.1.pdf page 38 of 66 (March 2008) defines a Garbled
message as[start quote]
BeginString (tag #8) is not the first tag in a message or is not of
the format 8=FIXT.n.m.BodyLength (tag #9) is not the second tag in a message or does not
contain the correct byte count.MsgType (tag #35) is not the third tag in a message.
Checksum (tag #10) is not the last tag or contains an incorrect value.
[End quote]
The following additions should be made to the above list of
definitions of a garbled messageSenderCompID (tag #49) is not the fourth tag in a message.
TargetCompID (tag #56) is not the fifth tag in a message.
ApplVerID (tag #1128) if present in message is not the sixth tag in a
message.Non numeric Tag is present in the message, for example ^X=123^
(Request :- If this is not the correct forum for discussing
FIX_Transport_1.1.pdf, please let me know the correct forum)Regards,
K. Mahesh
Mahesh,
My post you referenced confirmed that we were discussing it and if it was ratified it would have been as noted in that post and published as an errata.
That said, even though at the time we were close to agreement (thus the post prior to the ratification), but there was some last minute push back - strong enough push back that the errata was never ratified by the GTC Gov.
Lisa
Jim,
I thought the order given in FIXT Header Mapping Table on Page 31 of 66
is correct. This was confirmed by Lisa Taikitsadaporn of Brook Path
Partners athttp://fixprotocol.org/discuss/read/090515da
Regards,
K. MaheshMahesh, I don’t believe that we reached this consensus on FIXT.1.1 in
terms of extending the tag order to SenderCompID, TargetCompID and
ApplVerID. There was considerable push back.In FIX_Transport_1.1.pdf page 38 of 66 (March 2008) defines a
Garbled message as[start quote]
BeginString (tag #8) is not the first tag in a message or is not of
the format 8=FIXT.n.m.BodyLength (tag #9) is not the second tag in a message or does not
contain the correct byte count.MsgType (tag #35) is not the third tag in a message.
Checksum (tag #10) is not the last tag or contains an incorrect
value.[End quote]
The following additions should be made to the above list of
definitions of a garbled messageSenderCompID (tag #49) is not the fourth tag in a message.
TargetCompID (tag #56) is not the fifth tag in a message.
ApplVerID (tag #1128) if present in message is not the sixth tag in
a message.Non numeric Tag is present in the message, for example ^X=123^
(Request :- If this is not the correct forum for discussing
FIX_Transport_1.1.pdf, please let me know the correct forum)Regards,
K. Mahesh
Lisa,
I misunderstood your post that errata was for ApplVerID (1128) only and not for SenderCompID (49) and TargetCompID (56) which I assumed were already included in the extended tag ordering. Thanks for clarifying.
Regards,
K. Mahesh
Mahesh,
My post you referenced confirmed that we were discussing it and if it
was ratified it would have been as noted in that post and published as
an errata.That said, even though at the time we were close to agreement (thus the
post prior to the ratification), but there was some last minute push
back - strong enough push back that the errata was never ratified by
the GTC Gov.Lisa
Jim,
I thought the order given in FIXT Header Mapping Table on Page 31 of
66 is correct. This was confirmed by Lisa Taikitsadaporn of Brook Path
Partners athttp://fixprotocol.org/discuss/read/090515da
Regards,
K. MaheshMahesh, I don’t believe that we reached this consensus on FIXT.1.1
in terms of extending the tag order to SenderCompID, TargetCompID
and ApplVerID. There was considerable push back.In FIX_Transport_1.1.pdf page 38 of 66 (March 2008) defines a
Garbled message as[start quote]
BeginString (tag #8) is not the first tag in a message or is not
of the format 8=FIXT.n.m.BodyLength (tag #9) is not the second tag in a message or does not
contain the correct byte count.MsgType (tag #35) is not the third tag in a message.
Checksum (tag #10) is not the last tag or contains an incorrect
value.[End quote]
The following additions should be made to the above list of
definitions of a garbled messageSenderCompID (tag #49) is not the fourth tag in a message.
TargetCompID (tag #56) is not the fifth tag in a message.
ApplVerID (tag #1128) if present in message is not the sixth tag
in a message.Non numeric Tag is present in the message, for example ^X=123^
(Request :- If this is not the correct forum for discussing
FIX_Transport_1.1.pdf, please let me know the correct forum)Regards,
K. Mahesh
[ original email was from Clive Browning - clive.browning@rapidaddition.co.uk ]
Hi
To support overriding of the default FIX message (application) version specified in the logon message it is necessary that the ApplVerID (1128), ApplExtID (1156) and CstmApplVerID (1129) if they occur, do so in the message header before any of the application message fields that are versioned outside of the FIXT.1.1 specification. If this is not the ccase a FIX parser is unable to parse the FIX message correctly.
At the moment we have used the rule that these fields if they occur should appear directly after SenderCompID and TargetCompID… that is how we construct outbound FIX messages. Inbound we are more relaxed with our validation to cater for the 2 situations below…
The FIXT.1.1 spec (March 2008) is ambiguous… in the Standard Message Header section, page 17 the versioning fields are shown directly after the MsgType (35) field. Whilst in the section FIXT Header Mapping Table (page 31), ApplVerID is specified to be at position 6 if present, i.e. after the SenderCompID and TargetCompID tags.
I am ambivolent over which option is selected, but this does need to be tied down. Is the simple option to use the recommendation per the FIXT Header Mapping Table?
I think some arguments were put forward for having all the delivery fields before the versioning information (e.g. DeliverTo and OnBehalfOf tags)?
Thanks
Clive Browning
Rapid Addition Ltd
Lisa,
I misunderstood your post that errata was for ApplVerID (1128) only and
not for SenderCompID (49) and TargetCompID (56) which I assumed were
already included in the extended tag ordering. Thanks for clarifying.Regards,
K. MaheshMahesh,
My post you referenced confirmed that we were discussing it and if it
was ratified it would have been as noted in that post and published as
an errata.That said, even though at the time we were close to agreement (thus
the post prior to the ratification), but there was some last minute
push back - strong enough push back that the errata was never ratified
by the GTC Gov.Lisa
Jim,
I thought the order given in FIXT Header Mapping Table on Page 31 of
66 is correct. This was confirmed by Lisa Taikitsadaporn of Brook
Path Partners athttp://fixprotocol.org/discuss/read/090515da
Regards,
K. MaheshMahesh, I don’t believe that we reached this consensus on FIXT.1.1
in terms of extending the tag order to SenderCompID, TargetCompID
and ApplVerID. There was considerable push back.In FIX_Transport_1.1.pdf page 38 of 66 (March 2008) defines a
Garbled message as[start quote]
BeginString (tag #8) is not the first tag in a message or is not
of the format 8=FIXT.n.m.BodyLength (tag #9) is not the second tag in a message or does
not contain the correct byte count.MsgType (tag #35) is not the third tag in a message.
Checksum (tag #10) is not the last tag or contains an incorrect
value.[End quote]
The following additions should be made to the above list of
definitions of a garbled messageSenderCompID (tag #49) is not the fourth tag in a message.
TargetCompID (tag #56) is not the fifth tag in a message.
ApplVerID (tag #1128) if present in message is not the sixth tag
in a message.Non numeric Tag is present in the message, for example ^X=123^
(Request :- If this is not the correct forum for discussing
FIX_Transport_1.1.pdf, please let me know the correct forum)Regards,
K. Mahesh
Hi Clive,
I would recommend having all mandatory fields before any optional fields.
Regards,
K. Mahesh
Hi
To support overriding of the default FIX message (application) version
specified in the logon message it is necessary that the ApplVerID
(1128), ApplExtID (1156) and CstmApplVerID (1129) if they occur, do so
in the message header before any of the application message fields that
are versioned outside of the FIXT.1.1 specification. If this is not the
ccase a FIX parser is unable to parse the FIX message correctly.At the moment we have used the rule that these fields if they occur
should appear directly after SenderCompID and TargetCompID… that is
how we construct outbound FIX messages. Inbound we are more relaxed with
our validation to cater for the 2 situations below…The FIXT.1.1 spec (March 2008) is ambiguous… in the Standard Message
Header section, page 17 the versioning fields are shown directly after
the MsgType (35) field. Whilst in the section FIXT Header Mapping Table
(page 31), ApplVerID is specified to be at position 6 if present, i.e.
after the SenderCompID and TargetCompID tags.I am ambivolent over which option is selected, but this does need to be
tied down. Is the simple option to use the recommendation per the FIXT
Header Mapping Table?I think some arguments were put forward for having all the delivery
fields before the versioning information (e.g. DeliverTo and
OnBehalfOf tags)?Thanks
Clive Browning
Rapid Addition Ltd