[This message was posted by Hanno Klein of Deutsche Börse Systems <[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/d1fd4035 - PLEASE DO NOT REPLY BY MAIL.]
Hi Bernt, I would not silently ignore the field, assuming that the sender wanted to either convey information or ask for a certain trading behaviour. I consider it to be best practice to avoid sending redundant fields and to point it out to the sender if unexpected fields are sent. As it is functional information that cannot be processed by the specific receiver, the business level reject should be used. Other receivers might support the requested functionality and accept the message as is. Reducing the repository and converting it to a technical error does not seem the right approach to me. It could even lead to the wrong people on the sender side dealing with the error and then (rightfully) claiming that the receiver does not follow the FIX spec. Regards, Hanno. > 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.
