[This message was posted by Clive Browning of Rapid Addition Ltd <[email protected]> to the "Transport Independence Framework" discussion forum at http://fixprotocol.org/discuss/49. You can reply to it on-line at http://fixprotocol.org/discuss/read/cf0d814b - PLEASE DO NOT REPLY BY MAIL.]
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. 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 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 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 [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]]
-- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
