[This message was posted by Hanno Klein of Deutsche Börse Systems <hanno.kl...@deutsche-boerse.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/e7349fc7 - PLEASE DO NOT REPLY BY MAIL.]
Your "front door" can issue a MarketDataRequestReject if you want to reject it as early as possible. The user does not really care which component in your infrastructure creates the response. You might face challenges if you are missing required information at the point where you want to create the response. > 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.
