Imported from previous forum
FPL is proud to announce the availability of the FIX 5.0 Release Candidate by the Global Technical Committee. The release has been posted and is publicly available for download at: http://www.fixprotocol.org/documents/2924/FIX_5_0_Candidate.zip. The .zip file includes 7 volumes and Release Notes.
Please post all review comments, questions and feedback by replying to this discussion thread. The committee will use this discussion thread to archive and respond to all feedback received from the public.
Congratulations. One thing I noticed immediately when opening up index.html in the FIXimate directory is that it is still labeled as 4.4.
FPL is proud to announce the availability of the FIX 5.0 Release
Candidate by the Global Technical Committee. The release has been posted
and is publicly available for download at:
http://www.fixprotocol.org/documents/2924/FIX_5_0_Candidate.zip. The
.zip file includes 7 volumes and Release Notes.Please post all review comments, questions and feedback by replying to
this discussion thread. The committee will use this discussion thread to
archive and respond to all feedback received from the public.
Thank you Oren… we noticed that too and will fix the label for final release.
Congratulations. One thing I noticed immediately when opening up
index.html in the FIXimate directory is that it is still labeled as 4.4.FPL is proud to announce the availability of the FIX 5.0 Release
Candidate by the Global Technical Committee. The release has been
posted and is publicly available for download at:
http://www.fixprotocol.org/documents/2924/FIX_5_0_Candidate.zip. The
.zip file includes 7 volumes and Release Notes.Please post all review comments, questions and feedback by replying to
this discussion thread. The committee will use this discussion thread
to archive and respond to all feedback received from the public.
[ original email was from Henrik Johansson - henrik.johansson@omxgroup.com ]
Congratutaltions for your great work!
My immediate comments regarding the session FIX_Transport_1.1_draft_0.pdf
-
The document is not updated for FIX.5.0/FIXT.1.1, BeginString value is still FIX.4.4. Defintition of what a garbled message also needs an update (FIXT.n.m is now valid)
-
It would be nice if the length of value the BeginString is shortened with one byte (i.e. from FIXT.1.1 to for example FIT.1.1). The rationale is that a FIX-engine until now knows exacty where the BodyLen value starts (at position 12). Now it will either be on position 12 or position 13 due to the length of Beginstring.
-
The wording in the section dealing with NextExpectedMsgSeqNum is not changed (‘If accepted in the next major release of the protocol, its use will become mandatory’). Can we be clearer on when and if usage of this is mandatory or not?
-
There should be no references to application messages in this document, in Session Testcase 14l and 14m a BusinessMessage reject is expected when a conditionally req´d field is missin or if the system is not available. If a message validation fails in sessionlevel a session level reject should be sent. These specific testcases can perhaps be moved to application level validation outside this specific document
-
In the Session Testcases there are a number of references to different FIX-versions and expected behaviour are different depending on which FIX-version is used now. These messages, which are session messages, are defined in this document and they should be used as they are defined here. Refering to session-level messages for old FIX-versions (FIX 4.4 and earlier) does not add any value except for those who are using old session layer versions. Therefore these old references can be removed or be specified as deprecated.
Regards,
Henrik
[ original email was from Henrik Johansson - henrik.johansson@omxgroup.com ]
There is no introduction for the Trading Session List Request and the Trading Session List messages in Vol 3 pp98-99.
Rgds,
Henrik
Referenced tag numbers for CFICode and SecurityType wrong in multiple places of FIXimate and Volume 6, should be 461 and 167 (not 46 and 67)
Description redundant for a number of tags (once without and once with line breaks), typically where multiple valid values need to be described: 167 (SecurityType), 468 (RoundingDirection), 477 (DistribPaymentMethod), 480 (CancellationRights), 484 (ExecPriceType), 492 (PaymentMethod), 495 (TaxAdvantageType), 497 (FundRenewWaiv),…
Line breaks in a number of descriptions seem broken: 233 (StipulationType), 234 (StipulationValue),…
All errors seems to apply to FIXimate and Volume 6 in the same way.
FPL is proud to announce the availability of the FIX 5.0 Release
Candidate by the Global Technical Committee. The release has been posted
and is publicly available for download at:
http://www.fixprotocol.org/documents/2924/FIX_5_0_Candidate.zip. The
.zip file includes 7 volumes and Release Notes.Please post all review comments, questions and feedback by replying to
this discussion thread. The committee will use this discussion thread to
archive and respond to all feedback received from the public.
New values and messages are introduced. The doc is more complete, introduction of more diagrams for behaviour is really a good point, as a separate doc for session level.
However I don’t see any real core change from FIX4.4, which is good, but maybe this version should be named FIX.4.5?
New values and messages are introduced. The doc is more complete,
introduction of more diagrams for behaviour is really a good point, as a
separate doc for session level.However I don’t see any real core change from FIX4.4, which is good, but
maybe this version should be named FIX.4.5?
The impetus for calling this version FIX 5.0 is because of the introduction the transport independence (TI) framework. The GTC feels that this is an important departure from past FIX specifications where the session and application layers are coupled together. This is similar track the GTC took when the FIX session layer changed behavior between 2.7/3.0 (for those of you who used it) and 4.x. To accommodate TI we have changed the BeginString in the FIX session to be “FIXT.1.1” for the new session, thus identifying that you are using the TI framework. If you and your counterparty are using this new framework the old BeginString convention (e.g. BeginString=FIX.4.2) are no longer valid value. When using BeginString=FIXT.1.1 your application layer messages can be any version of FIX you want it to be (4.0, 4.2, 4.4, 5.0, etc.) - see the use cases described in Vol. 2 of the specification package.
From an application functionality perspective, you are correct, there is not real core change at that layer.
[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
The New Order Multileg message has the SwapPoints (1069) tag. However it is not represented in the Multileg Order Cancel Replace message. I am not an expert on this, so I cannot say it is wrong, just wanted you to know…
Regards
Rikard
[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
Market Data messages show a new tag, MDQuoteType. The field does not have a set of defined enum values although the field defintion indicates that such would be the case. Is it the intention that such values should be agreed between the parties?
Regards
Rikard
(PS posted this in the wrong thread initially, sorry)
[ original email was from Matt Simpson - msimpson@cme.com ]
The enums for MDQuoteType will be the same as QuoteType. We are tracking this as an issue and it will be corrected in the final release.
Market Data messages show a new tag, MDQuoteType. The field does not
have a set of defined enum values although the field defintion indicates
that such would be the case. Is it the intention that such values should
be agreed between the parties?Regards
Rikard
(PS posted this in the wrong thread initially, sorry)
[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
The volume 3 section on “Market Data - Snapshot / Full Refresh” contains the following bullet point:
“Messages containing bids and/or offers cannot contain trades, imbalances, index value, opening, closing, settlement, high, low, and/or VWAP prices, trade volume, or open interest.”
However, the MDEntry part of the message contains the 332 (HighPx), 333 (LowPX) and 1020 (TradeVolume) fields. I belive it was reasoned that we provide these values instead of supporting indicators for whether to update Hi/Lo/Volume.
I would propose that the bullet point is changed so we allow the fields, but clarify that the same data should not be included in one message as separate MDEntries, i.e. something like:
“Messages containing bids and/or offers cannot contain trades, imbalances, index value, opening, closing, settlement, high, low, and/or VWAP prices, trade volume, or open interest as separate entries.”
Regards
Rikard
(PS posted this in the wrong thread initially, sorry)
[ original email was from John Falvey - jffalvey@statestreet.com ]
> FPL is proud to announce the availability of the FIX 5.0 Release
Candidate by the Global Technical Committee. The release has been posted
and is publicly available for download at:
http://www.fixprotocol.org/documents/2924/FIX_5_0_Candidate.zip. The
.zip file includes 7 volumes and Release Notes.Please post all review comments, questions and feedback by replying to
this discussion thread. The committee will use this discussion thread to
archive and respond to all feedback received from the public.
I do not use this field, but In Vol 6 I happened upon the tag 1134(ReportedPxDiff). Its type is boolean, but the valid values are listed as an enumeration. Is the type incorrect?
John
[ original email was from Andrew Thompson - anthomps@blackrock.com ]
I noticed the definition of TZTimestamp and TZTimeOnly do not allow milliseconds, which is inconsistent with the definitions of UTCTimestamp and UTCTimeOnly.
Was this intentional? It would be a great shame if millis are not allowed as they are very useful for understanding log files, and consistency would seem the simplest course of action.
[ original email was from Andrew Thompson - anthomps@blackrock.com ]
I’ve spotted what appear to be copy-paste mistakes and a couple of possible errors in the FX examples in volume 7 of the 5.0 spec, beginning on page 165.
Typos / Copy Paste
pg 172 - In 6 instances in the last 2 examples, the descriptions for tags 637, 675and 1073 read “near leg” when they should clearly be “far leg”
Possible errors
- Incorrect value for Spot Tenor
pg 165. The first examples is described as a Spot/Forward (1M) example. However, the first instance of LegSettlType (587) reads:
587=1 (Cash/TOD (T+0).
This is incorrect if it is meant to be a spot example. As defined on vol 7, pg 153 the correct value is
587=0 (Regular/Spot (T+1) or (T+2)
The same apparent error is repeated on pgs 166 and 171
- Points given incorrectly
At the top of vol. 7 pg 154, point 7 it states “Points” fields are to be given in decimal form. In several examples Points have been given as points…
pg 166: 1068=20.75 -> 1068=0.002075
pg 167: 1065 and 1066 are given incorrectly
pg 172: 1073 is incorrect
- Incorrect value for Spot Tenor in Market Data
On page 169, in 4 places we see
63=B with the comment //[1] SettlType - Spot
However, the definition of “B” is “broken dated” (i.e. settlement does not occur on a standard tenor). It should be
63=0
Having said that, in these examples tag 64 is 2005/09/23 and the example, based on the value in tag 262 is implied to be a message sent on 2005/09/22. Thus 63=1 (T+1/TOM) would be more consistent, as this isn’t USD/CAD. If the intention is to show spot, ideally fix 262 to imply 2005/09/21 and make 63=0 in all 4 cases.
Finally, on a more philosophical note - the FX usage clearly states the initiator’s response to accept a Quote message should be a New Order - Single. Whereas the intention of the protocol designers was clearly that the initiator respond with a Quote Response Type=Hit/Lift to trade on a Quote.
I can see why this might have been done, but doesn’t it at least deserve some comment?