ApplVerID vs CstmApplVerID

, ,
1

Imported from previous forum

2

Are the precise semantics of the ApplVerID and CstmApplVerID defined somewhere? I can’t seem to find them. I don’t mean the fields them selves but how they interact and coexists.

Are they supposed to be mutually exclusive or should they always appear together? There is a mandatory DefaultApplVerID on the Logon message so in practice there would always be an application version in play even if the CstmApplVerID was specified.

Actually, I’d propose a simplification here: drop the CstmApplVerID as a separate identifier. Instead, use the concept of a single version indentification mechanism. The version together with the name of a message type unambiguously identifies the type of a message. Whether a particular version is a blessed service pack or an extension pack is satellite metadata that doesn’t need to be conveyed in every message on the wire.

/David

3

David -

You can find some information on the usage of ApplVerID and CstmApplVerID in the document entitled Transport Independence, Service Packs and Application Versioning which is posted to the GTC page at the following link
http://fixprotocol.org/documents/3206/FIX%20Protocol%20Gap%20Analysis%20ServicePacks%20and%20Versioning_v091.doc

The intention is that ApplVerID be used to state the base release of a given message. If necessary, CstmApplVerID would be used to specify a bilaterally agreed to custom extension of that base release. The document also makes allowance for the use of CstmApplVerID in conveying an approved extension pack where extension pack identifiers are assigned by the GTC and are sequential in nature, i.e. EP49, EP50, etc (where EP stands for extension pack). There is a need to address the use case where an EP + Custom extension is used.

Bandwidth was deemed a consideration in using separate fields to identify application versions. ApplVerID can be concisely enumerated using, for example, a value of 7 which represents “FIX.5.0” or 8 for “FIX.5.0 SP1” as service packs are introduced.

Are the precise semantics of the ApplVerID and CstmApplVerID defined
somewhere? I can’t seem to find them. I don’t mean the fields them
selves but how they interact and coexists.

Are they supposed to be mutually exclusive or should they always appear
together? There is a mandatory DefaultApplVerID on the Logon message so
in practice there would always be an application version in play even if
the CstmApplVerID was specified.

Actually, I’d propose a simplification here: drop the CstmApplVerID as
a separate identifier. Instead, use the concept of a single version
indentification mechanism. The version together with the name of a
message type unambiguously identifies the type of a message. Whether a
particular version is a blessed service pack or an extension pack is
satellite metadata that doesn’t need to be conveyed in every message
on the wire.

/David

4

Ok, thanks for the pointer.

However, the document doesn’t seem to clearly specify whether the CstmApplVerID is sufficient in it self to identify a particular version of a message or if the domain is local to the specified ApplVerID in which case you’d need booth. Nevertheless, I’m reading the document to mean that given a particular extension pack number, the underlying service pack follows implicitly.

This would mean that specifying the extension pack number alone is all you need. Which further means that the two versions could be combined into one identifier.

The combined identifier would still be an enumeration so size wouldn’t be a problem. Since it is GTC that assignes both service and extension pack numbers, the sequence could be continuous. For example

7 = FIX 5.0
8 = FIX 5.0 EP 1
9 = FIX 5.0 EP 2
10 = FIX 5.0 SP 1 // Includes EP 1 & 2
…

And you could allow for custom extension identifiers in an upper range

4000 = FIX 5.0 EP 2 with some extra sugar on top

/David

David -

You can find some information on the usage of ApplVerID and
CstmApplVerID in the document entitled Transport Independence, Service
Packs and Application Versioning which is posted to the GTC page at the
following link http://fixprotocol.org/documents/3206/FIX%20Protocol%20G-
ap%20Analysis%20ServicePacks%20and%20Versioning_v091.doc

The intention is that ApplVerID be used to state the base release of a
given message. If necessary, CstmApplVerID would be used to specify a
bilaterally agreed to custom extension of that base release. The
document also makes allowance for the use of CstmApplVerID in conveying
an approved extension pack where extension pack identifiers are assigned
by the GTC and are sequential in nature, i.e. EP49, EP50, etc (where EP
stands for extension pack). There is a need to address the use case
where an EP + Custom extension is used.

Bandwidth was deemed a consideration in using separate fields to
identify application versions. ApplVerID can be concisely enumerated
using, for example, a value of 7 which represents “FIX.5.0” or 8 for
“FIX.5.0 SP1” as service packs are introduced.

5

The original plan was to provide new enumerations for ApplVerID only as new service packs were released - not for each extension pack. Early adopters could use an EP prior to official release in an SP by referencing it in CstmApplVerID (per the value assigned by the GTC).

This has the benefit of reducing the number of “application versions” that are available. It is common for an SP to contain as many as 10-15 EP’s.

The downside is that early adoptors must drop their reference to the EP in CstmApplVerID and begin using the ApplVerID enumeration which represents that SP once it is released.

We should discuss both approaches in the FIX 5.0 Usage Group.

Ok, thanks for the pointer.

However, the document doesn’t seem to clearly specify whether the
CstmApplVerID is sufficient in it self to identify a particular version
of a message or if the domain is local to the specified ApplVerID in
which case you’d need booth. Nevertheless, I’m reading the document to
mean that given a particular extension pack number, the underlying
service pack follows implicitly.

This would mean that specifying the extension pack number alone is all
you need. Which further means that the two versions could be combined
into one identifier.

The combined identifier would still be an enumeration so size wouldn’t
be a problem. Since it is GTC that assignes both service and extension
pack numbers, the sequence could be continuous. For example

7 = FIX 5.0 8 = FIX 5.0 EP 1 9 = FIX 5.0 EP 2 10 = FIX 5.0 SP 1 //
Includes EP 1 & 2 …

And you could allow for custom extension identifiers in an upper range

4000 = FIX 5.0 EP 2 with some extra sugar on top

/David