Hi,
Can you confirm that the message type 35=n (XML non-FIX) is considered a session/admin level message and that a popular FIX engine is right to treat it as such by default? Is this something that is open to interpretation (and therefore custom logic to handle it appropriately).
We are receiving messages of this type from large vendors/marketplaces with trade/business information that seems in contradiction to this (i.e. they’re treating it as an application message, or expect us to do so). I’ve also seen FIX4.4 dictionaries classify it as an application message type.
The XML non-FIX message is currently classified as a session layer message. I think the message can be considered an application level message. It’s adoption to date has been used to transport FpML for OTC derivatives processing: http://www.fpml.org/docs/FpML-transport-guidelines.pdf
The B3 (formerly BVMF Bovespa) has adopted the FIX session and FIX 35=n message to transmit ISO 20022 XML (with extensions). for clearing and settlement across their multiple clearing houses.
I suppose the way to think about it is a session level message used to transport (envelope) other application level protocols (FpML, ISO 20022, etc.).
There is a strong argument that can be made that 35=n should be an application level message.
Also, I think it is important that 35=n can be used to transport any type of payload (JSON for instance) or Simple Binary Encoding (SBE) or Google Protocol Buffers (GPB) not just XML.
I spent a bit more time thinking about your question. I agree that one should assume that everything within the session layer should be dealt with at the FIX engine level. In that regard there is little a FIX engine can do to process a 35=n (XML non-FIX) message. It must be handed up to an application processor for decoding and processing.
One could argue that resend requests and logon messages could cross the boundaries and require some application processor, but in general these messages are true session layer messages and can be processed by a FIX engine by default. That an implementation has decided to pass the logon up to an application processor or that an implementation has decided that the application must make the decision on resending messages does not make them non-session level. The 35=n message (poorly named as it is) dictates some application outside of the FIX session processing is required.
We should rename the message and also move it to the Infrastructure category at the application level I suspect or renamed to be non-FIX application level content and remain in the session layer as a way that non-FIX applications can use the FIX session layer.