[This message was posted by Mahesh Kumaraguru of <[email protected]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/875add9d - PLEASE DO NOT REPLY BY MAIL.]
Hi Jim, This sounds like a good idea that firms who do not want application version independence or transport independence simply use 8=FIX.5.0, 8=FIX.5.0SP1, 8=FIX.5.0SP2, etc. Regarding FIXT.1.2, the following are my thoughts 1. Let all Session messages (Heartbeat, TestRequest, ResendRequest, SessionLevelReject, SequenceReset, Logout and Logon) use BeginString 8=FIXT.1.2 2. Logon message should contain a list of permitted application versions using Start Component = PermittedApplVersions Start Repeating Group = NoPermittedApplVersions First Reqd field = PermittedApplVersion Next Opt field = PermittedApplExtID Next Opt field = PermittedCstmApplID MsgTypeGrp component can be nested within this new Component PermittedApplVersions (or vice versa) so that versions can be specified by message type. When a FIX engine receives a Logon message, it can validate this list with its counterparty configuration. If the FIX Engine finds a version it does not support / did not agree to support with the given counterparty, the FIX Engine can send a logout with 58="Invalid version FIX.x.y" 3. Define a new Enumeration Tag for Specifying the Logout reason and add it to Logout message. Some values that come to mind are EndOfDay Low Sequence number FIX version not supported etc. 4.1 Let all Application messages (too many to list here) use BeginString 8=FIX.n.m (without the "T"). If a Application message is received which has a BeginString which is not supported / not in the List 2. above, then a Session level reject can be sent with 58="Invalid version FIX.n.m" and SessionRejectReason 373=18 Invalid/Unsupported Application Version. 4.2 Alternately, should the receipt of an unsupported version message be considered such a serious error that a Logout is issued ? In which case I would recommend adding 45 RefSeqNum and 372 RefMsgType to the logout message so that the counterparty who receives a logout due to an invalid version can dig thru their FIX log more easily. 4.3 Given this setup, there would be no need for ApplVerID(1128), DefaultApplVerID(1137) and related fields because each application message will have its version in begin string. 4.4 When a FIX Engine receives a message which does not BeginString 8=FIXT.p.q, the FIX Engine knows that it has to be an Application message and applies version versus message type check, applies all Session level validations, translates the FIX message into a message / object of the protocol between FIX Engine and Trading application and hands it over to the appropriate trading application. I assume there would be multiple trading applications behind the FIX Engine one for each supported version. Regards, K. Mahesh > I think polling each FIX member organization and giving them some form > of proportional representation on important strategic decisions makes > considerable sense. > > I am submitting a proposal to permit firms without the need for > application version independence or transport independence to simply use > 8=FIX.5.0, 8=FIX.5.0SP1, 8=FIX.5.0SP2, etc. > > We could then let the industry choose for themselves. > > The alternative is to come out with a FIXT.1.2 to address limitations in > the current FIXT.1.1. > > Either way we end up with two approaches that must be implemented and > supported - why not make that second approach match the original simple > and successful approach taking with FIX.2.7-FIX.4.4? > > It is time for practicality so that firms can start to easily access the > very valuable business functionality locked within FIX.5.0. > > This issue can literally be changed with a stroke of a pen. [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.
