[This message was posted by John Peng of IIROC <[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/ddbf2cb3 - PLEASE DO NOT REPLY BY MAIL.]
I would say that option 3 is the way to go. Be careful thought that the custom FIX repository is supposed to be a true reflection of your own FIX spec -- so you only exclude the fields that are not supported in your spec. In other words, no "creativity" is allowed in the repository itself, and any change should start with your spec. Just my two cents... > Hi, > > I can think of the following ways of handling unsupported > optional fields: > > 1) Silently ignore the field. > 2) Send a business level reject, for example an ExecutionReport to > reject a New Order Single, indicating that the field is not > supported. 3) Exclude the non supported field in our FIX repository > which will have the effect that we send a session level reject > instead with 373=3 (undefined tag) as we do not recognize that tag. > > Please advise > > Regards, Bernt [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.
