[This message was posted by Dennis Wiatzka of Nasdaq OMX 
<[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/00b1fa53 - PLEASE DO NOT REPLY BY MAIL.]

Hello Lalin,

Yes, anytime a standard FIX tag is specified with a value not valid according 
to the specification the appropriate response is a session level reject with 
values set appropriately.

Best regards,

Dennis

> Thanks again Dennis.
> 
> I have a follow up question. What if the Application Message Request included 
> an ApplReqType (1347) not defined in the FIX specification (e.g. 1347 = 
> 100000)? Should such a message still be rejected via an Application Message 
> Request Ack? Or should the session-level Reject message (with a 
> SessionRejectReason (373) of 5 [value is incorrect (out of range) for this 
> tag] be used?
> 
> 
> 
> > Hi again,
> > 
> > It appears as though the best response is ApplicationMessageRequestAck with 
> > tag 1348 value 2 (Messages not available) with tag 58 text stating tag 1347 
> > with value 3 is not supported by your application.
> > 
> > Down the road it would appear that ApplicationMessageRequestAck should be 
> > enhanced so tag 1348 has a new value which can indicate that the request 
> > type is not supported by the receiving application.
> > 
> > Regards, Dennis
> > 
> > > Thanks for the response Dennis.
> > > 
> > > I may have been a little unclear with my example. What I meant to say was 
> > > how should, for example, an incoming Application Message Request with an 
> > > ApplReqType (1347) of 3 (request valid set of applications) be rejected 
> > > if the receiving application supports the Application Message Request but 
> > > not the ApplReqType of 3?
> > > 
> > > 
> > > > > What would be the most appropriate message to reject an incoming 
> > > > > message with a tag containing a value defined in the FIX 
> > > > > specification but not supported by the receiving application? Is it 
> > > > > appropriate to use a Reject (i.e. session level) with a 
> > > > > SessionRejectReason (373) of 5 (value is incorrect (out of range) for 
> > > > > this tag) in such a scenario?
> > > > > 
> > > > 
> > > > Do not use a session level reject. Send an appropriate response message 
> > > > (exec report for a new order, order cxl rej for chg/cxl request, etc.), 
> > > > with reject codes set as best as possible and with text clearly stating 
> > > > the tag and value that your application does not support.
> > > > 
> > > > > How should, for example, an incoming Application Message Request with 
> > > > > an ApplReqType (1347) of 3 (request valid set of applications) be 
> > > > > rejected if the receiving application does not support such a request?
> > > > 
> > > > When your application does not support a requested message you can send 
> > > > Business Message Reject with BusinessRejectReason = “Unsupported 
> > > > Message Type”. Alternatively you can implement support for the specific 
> > > > response message solely for the purpose of rejecting such requests but 
> > > > most often it seems folks use the Business Message Reject message.


[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.

Reply via email to