[This message was posted by Jeffrey Croft of Plus Markets Group <jeff.cr...@plusmarketsgroup.com> to the "4.4 Changes" discussion forum at http://fixprotocol.org/discuss/17. You can reply to it on-line at http://fixprotocol.org/discuss/read/56f1d4e2 - PLEASE DO NOT REPLY BY MAIL.]
I guess for most implementations though (ours included) it would be more efficient to reject it at the front door rather than pass it across to the Business tier. > If the RoE reduce the list of valid values, it needs to be the application > layer that rejects it, not the session layer (FIX Engine). > > Your case is easy, i.e. send a MarketDataRequestReject with 281 > MDReqRejReason = 5 = Unsupported MarketDepth. > > You can choose in your RoE to interpret unsupported values in some other way > and not reject the requets but I would caution against that. > > > If a participant sends in a request type message with an unsupported > > enumeration/option should the message be rejected outright? > > > > As example, lets say the participant sends in a MarketDataRequest with a > > MarketDepth <264> value of '0 = full book depth'. If the ROE states we > > support only a value of '1 = top of book' then should we reject or send > > them what we say we provide? (could be dangerous in some cases). > > > > In general should a request be rejected if the inbound message contains an > > unsupported enumeration/option? [You can unsubscribe from this discussion group by sending a message to mailto:unsubscribe+100932...@fixprotocol.org] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to fix-proto...@googlegroups.com. To unsubscribe from this group, send email to fix-protocol+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
