Imported from previous forum
We have had a couple of more issues come up between FIXT.1.1 and FIX Application level messages. Issues 1) Adding features to standard header and session level messages – forcing a change to the FIX session layer. 2)Where and how does the FIX standard header/ trailer and session level messages map into a specific version of FIX. 3)ApplVerID is conceptually maintained within FIXT.1.1, yet it is an enumerated list of application versions so each service pack conceptually breaks the FIXT layer. 4)Current engine vendors seem to be concerned about removing standard header, trailer, and session layer messages from FIX Application version repositories. 5)We are considering creating Session Extension Packs to get around the above issues. We have addressed #2 by providing a mapping between FIX session layers and the FIX application layer. We proposed addressing #3 by removing the enumeration from the FIXT level. We need to add some fields to the logon message to identify SystemID. We will soon be adding some fields to support throttling. Currently we cannot implement those within FIXT without a version change. BUT, let’s say we finesse the concept a little bit. Try and go with me here. The current repository currently has standard header, standard trailer, session level messages as part of each application level version of the FIX Repository. From a rules and concept perspective I would like to propose that we leave Standard Header, Standard Trailer, Session Layer messages as part of each version of FIX. So that each new service pack will include (as it does now) versions of Standard Header, Standard Trailer, Session Layer messages. There would also be maintained (as is the case right now) a set of Standard Header, Standard Trailer, Session Layer messages that are defined as part of FIXT.1.1. The begin string would remain 8=FIXT.1.1 in all cases as is currently the case. This would mean that if you are using FIX tag=value version over FIXT you use the Standard Header, Standard Trailer, Session Layer messages that are provided in the repository for the FIX tag=value version you are using. This resolves problems 1 to 5 very cleanly – we can add new functionality, ApplVerID is updated cleanly, FIX engine implementation is simpler in that the standard header, trailer, and session layer are includes as they always have been, we no longer need session extension packs (at least we can defer introducing the concept for some time). Do we lose version independence? I don’t think so. One could still include messages from later service packs using this approach. There already was a mapping exercise (albeit very trivial) to support earlier FIX.4.x versions over FIXT – that will not change. This really does seem to clean up our remaining issues with FIXT and FIX.5.x – I like this approach. If you want to use FIXT without a FIX tag=value version then you use the FIXT supplied Standard Header, Standard Trailer, and session layer messages. Thoughts?
Right now we include StandardHeader, StandardTrailer,SessionLayer messages in both the application version repositories, such as FIX.5.0SP1, FIX.5.0SP2 AND the FIXT.1.1 session level repository.
If we continue on the path that any changes to StandardHeader, StandardTrailer, and Session level messages would be made at the FIXT level and be a new version of FIXT.1.1 and FIXT.2.0 – then which StandardHeader, StandardTrailer, SessionLayer messages do we include in FIX.5.0, FIX.5.0SP1, FIX.50SP2 repositories when a new transport is defined and released? Do we include FIXT.1.1? FIXT.1.2? FIXT.2.0?
My take on this is we either cut the cord and fully commit to this layered architecture and fully remove the StandardHeader,StandardTrailer,SessionLayer from the application level repositories (FIX.5.0, FIX.5.0SP1, etc.) OR we follow the earlier proposal of mine above that recommends the contents of StandardHeader, StandardTrailer, and Session level messages is governed by the application layer and the semantics of the session layer and the encoding of FIX messages is governed by the FIXT version.
Either approach is fine and workable – but what we have right now is not correct and will not be workable as soon as the next transport version is released.
Thoughts?
I think we need to consider removing the standardheader, trailer, and session level messages from the FIX.5.x.x Repositories and only include their content in the FIXT repositories.
We could definitely write some scripts that would take a FIXT + FIX.5.0SPx repositories and create a combined repository – trivial to write.
If we don’t we are immediately going to hit a snag when someone releases FIXT.1.2 or FIXT.2.0 – it just won’t work - which versions of the StandardHeader,Trailer, and Session Level messages will be bundled with the FIX.5.0x repositories?
The other problem we have is that Fields are used by both the FIXT and the FIX.5.x – same number range making it difficult to split up. One approach would be to keep the fields dictionary independent of FIXT and FIX.5.x and shared across all versions. Unfortunately since we have renamed fields and reused tags we cannot create a single unified fields file across all versions.
In FIXT.1.1 we would make ApplVerID an integer unbounded to keep from having to change the FIXT.1.1 specification each time there is a new service pack created.
I think we should scrap the idea of Session Extension Packs – things are too complex already.