Why is 35=n (XML_non_FIX) defined as a Session message rather than an Application message ?

, ,
1

Imported from previous forum

2

[Start Quote from FIX.4.3 spec Vol 1 Page 9/49]

Introduction

The session level is concerned with the delivery of data while the application level defines business related data content.

[End Quote]

I am quoting from the FIX.4.3 spec because XML_non_FIX was introduced in FIX.4.3, but this definition is the same in earlier versions also. Other Session messages help the connected FIX Engines maintain a stable Session.

[Start Quote from FIX.4.3 spec Vol 2 page 3 / 63]

TRANSMITTING FIXML OR OTHER XML-BASED CONTENT

It is possible to send FIXML or other XML-based content (“payload”) via the FIX Session Protocol. The FIXML or other XML-based content is enclosed in a traditional “Tag=Value” FIX standard header via the standard header’s XmlDataLen and XmlData fields and followed by the “Tag=Value” FIX standard trailer.

The generic MsgType field value for “XML message (e.g. non-FIX MsgType)” can be used when transmitting XML content which is not defined with a FIX MsgType.

[End Quote]

So the XML_non_FIX message would not have any content of value to the FIX Engine to maintain a stable Session and fits the definition of delivery of application level / business related data content which is defined as payload in. So the FIX Engine after Session level validation of a 35=n message would forward it to a business application for use / processing.

Just curious why is 35=n (XML_non_FIX) defined as a Session message rather than an Application message ? Is there any use case where XML_non_FIX is used to control the behaviour of a Session ?

Regards,
K. Mahesh

3

This can be argued either way, but from a practical standpoint MsgType n is provided as an alternative for XML payload and has been placed with session layer to make it available for implementers not requiring FIX. This is one of the great advantages of FIXT being overlooked by the industry (possibly the only one).

[Start Quote from FIX.4.3 spec Vol 1 Page 9/49]

Introduction

The session level is concerned with the delivery of data while the
application level defines business related data content.

[End Quote]

I am quoting from the FIX.4.3 spec because XML_non_FIX was introduced
in FIX.4.3, but this definition is the same in earlier versions also.
Other Session messages help the connected FIX Engines maintain a
stable Session.

[Start Quote from FIX.4.3 spec Vol 2 page 3 / 63]

TRANSMITTING FIXML OR OTHER XML-BASED CONTENT

It is possible to send FIXML or other XML-based content (“payload”) via
the FIX Session Protocol. The FIXML or other XML-based content is
enclosed in a traditional “Tag=Value” FIX standard header via the
standard header’s XmlDataLen and XmlData fields and followed by the
“Tag=Value” FIX standard trailer.

The generic MsgType field value for “XML message (e.g. non-FIX MsgType)”
can be used when transmitting XML content which is not defined with a
FIX MsgType.

[End Quote]

So the XML_non_FIX message would not have any content of value to the
FIX Engine to maintain a stable Session and fits the definition of
delivery of application level / business related data content which is
defined as payload in. So the FIX Engine after Session level validation
of a 35=n message would forward it to a business application for use /
processing.

Just curious why is 35=n (XML_non_FIX) defined as a Session message
rather than an Application message ? Is there any use case where
XML_non_FIX is used to control the behaviour of a Session ?

Regards,
K. Mahesh