The FIX Time Precision Technical Addendum refers to types which are in FIX EP21 but not in the base 4.4 specification.
Where can information on EP21 and EPs from a similar time-period be located (they are not on the EP pages listing)?
Older EPs became part of the next FIX version, in this case FIX 5.0. They have not been published individually but only as part of the version-specific documentation. The FIX 5.0 release notes describe EP21 FX Phase 1 Extension) as follows:
The FX Phase 1 Extension covers Spot, Forwards, FX Swaps and vanilla FX OTC Spot Options. The functionality for each of the instruments covers Streaming prices for spots and outright forwards, Quotes for spots, outright forwards and FX swaps, Orders, Executions and Trade Capture (FX OTC Spot Options only).
The two additional data types TZTimeOnly and TZTimestamp were apparently added as part of EP21. The addendum fully describes their nature. I doubt that there is more to be found in the EP21 document related to the new data types.
Have a look at the FIX 5.0 release notes to find information on EPs between FIX 4.4 and FIX 5.0 base specification.
Thanks Hanno. The question isn’t so much about the addendum but the availability of the older EPs should someone require/desire them. If for example you wanted to create a 4.4 implementation that was cumulative of all 4.4 EPs then the information to do that is not there.
The natural related question is, why would you want to do such a thing? Then comes the question, when is a standard not standard?! Because whilst 4.2 and 4.4 are still in widespread use, the web site says you can go ahead and use any tags you want from 5.0 onwards in 4.4.
One last question; are you single handedly tasked with policing the forum, and, as punishment for what? 
Ok, maybe we still have a misunderstanding on how EPs were published prior to FIX 5.0 SP2 and after FIX 5.0 SP2. FIX 4.4 with all of “its” EPs is identical to FIX 5.0. That means that FIX 5.0 contains all information needed to implement FIX 4.4 with any or all of “its” EPs. Note that an implementation of pure FIX 4.4 for example does not include any EPs created afterwards. The EPs always belonged to the next version of FIX, hence I put “its” in quotes as that is a false perception.
Prior to FIX 5.0 SP2, EPs were not official until they were released as integral part of the specifcation (Volume 1-7). After FIX 5.0 SP2 we decided to publish EPs immediately together with their documentation instead of integrating them from time to time as part of a new FIX version. People then no longer had to wait but could use new tags from an EP as soon as it was published. The disadvantage is that people may have to look at multiple documents instead of seeing everything in Volume 1-7.
No worries, no punishment, just a real interest in getting people to adopt standards. That requires people to understand, otherwise they will not use it correctly which defeats the whole purpose.
Thanks, and interesting. I presume because there are member and regulatory drivers behind some of the EP activity, that an ‘implementor’ of FIX 5.0 SP2 would now be more likely to jump straight to the latest EP level (240 today) and that there would now be no real rationale for creation of a vanilla FIX 5.0 SP2 implementation?
Very good point and yes, the notion of FIX versions is now much less relevant. Bilaterally agreed Rules of Engagement define the set of messages, fields and valid values supported between the counterparties. Hence the policy of being able to use tags from higher versions (incuding EPs). This leads to the philosophical question if for example a FIX 4.4 interface using tags from higher versions is still a FIX 4.4 interface. The supported set is driven by the business requirements and we want people to be able to use FIX Latest, i.e. the richest set possible.
There is still a technical element when using the tag=value encoding (aka classic FIX) nad not FIXML, FAST, SBE or any other of the additional encodings for FIX. There you have a field BeginString(8) which used to carry the FIX version prior to FIX Version 5.0. With FIX Generation 5, this field was set to a constant value “FIXT.1.1” reflecting a specific session layer. However, FIX Generation 5 introduced the concept of Transport Independence which allows you to use any session layer, including commerical products. Additional FIX session layers (FIXP, LFIXT) are work in progress, i.e. we need to revisit this topic for use cases where people want to send tag=value syntax over the high performance session layer FIXP.
The vision for FIX engines of “Generation 6” is to provide version interoperability, allowing legacy versions of FIX to communicate with any other legacy version as well as with FIX Latest, removing the need to upgrade to a higher FIX version.