Imported from previous forum
[ original email was from Ryan Pierce (FPL Technical Director) - ryan.pierce@fixprotocol.org ]
During recent discussions, a question came up concerning how to tunnel FIXML over the Tag=Value FIX session layer, either, say, 4.4 or FIXT.1.1.
First, is anyone doing it today?
Second, what MsgType is used? For a Trade Capture Report, would it be “AE” or “n”?
The FIX 4.4 and FIXT.1.1 specs both say:
“The generic MsgType field (tag 35) value of “n” (lowercase n) for “XML message (e.g. non-FIX MsgType)” can be used when transmitting XML content which is not defined with a FIX MsgType.”
So it seems clear that for an entirely non-FIX message, like FpML, MsgType=“n” is required. But does this imply that a FIXML message needs to use the same MsgType it would use were it sent in Tag=Value format?
I think when FIXML is tunnelled over FIX tag=value, message type should be n.
If Message type AE is used, then XMLDataLen(212) and XMLData(213) will contain the FIXML block but the FIX engine would be expecting to find Required / Conditionally required fields in the Tag=value syntax and that content would also be present in FIXML. Providing data in both tag=value and FIXML will lead to redundancy / duplication and associated problems.
During recent discussions, a question came up concerning how to
tunnel FIXML over the Tag=Value FIX session layer, either, say, 4.4
or FIXT.1.1.First, is anyone doing it today?
Second, what MsgType is used? For a Trade Capture Report, would it be
“AE” or “n”?The FIX 4.4 and FIXT.1.1 specs both say:
“The generic MsgType field (tag 35) value of “n” (lowercase n) for “XML
message (e.g. non-FIX MsgType)” can be used when transmitting XML
content which is not defined with a FIX MsgType.”So it seems clear that for an entirely non-FIX message, like FpML,
MsgType=“n” is required. But does this imply that a FIXML message needs
to use the same MsgType it would use were it sent in Tag=Value format?
Mahesh - thanks for raising this issue again - I had forgotten this discussion.
I think the best way to communicate FIXML over FIX is to use FIXT.1.1 and use the XML_non_FIX (unfortunately named message) MsgType(tag 35)=‘n’.
FIXT.1.1 is ideal for sending non-FIX or company proprietary messages - I don’t know why we haven’t been selling this concept more.
With FIXT.1.1 since there is a separation between session and application layer - an application protocol for FIXML payload could be defined that would not include any FIX tags whatsoever - and list the MsgType enumerations for the FIXML messages being transmitted.
I see the value of FIXT.1.1 being outside of FIX not when used with FIX tag=value application versions.
I think when FIXML is tunnelled over FIX tag=value, message type
should be n.If Message type AE is used, then XMLDataLen(212) and XMLData(213) will
contain the FIXML block but the FIX engine would be expecting to find
Required / Conditionally required fields in the Tag=value syntax and
that content would also be present in FIXML. Providing data in both
tag=value and FIXML will lead to redundancy / duplication and
associated problems.During recent discussions, a question came up concerning how to tunnel
FIXML over the Tag=Value FIX session layer, either, say, 4.4 or
FIXT.1.1.First, is anyone doing it today?
Second, what MsgType is used? For a Trade Capture Report, would it be
“AE” or “n”?The FIX 4.4 and FIXT.1.1 specs both say:
“The generic MsgType field (tag 35) value of “n” (lowercase n) for
“XML message (e.g. non-FIX MsgType)” can be used when transmitting XML
content which is not defined with a FIX MsgType.”So it seems clear that for an entirely non-FIX message, like FpML,
MsgType=“n” is required. But does this imply that a FIXML message
needs to use the same MsgType it would use were it sent in
Tag=Value format?
Mahesh - thanks for raising this issue again - I had forgotten this
discussion.I think the best way to communicate FIXML over FIX is to use
FIXT.1.1 and use the XML_non_FIX (unfortunately named message)
MsgType(tag 35)=‘n’.FIXT.1.1 is ideal for sending non-FIX or company proprietary messages -
I don’t know why we haven’t been selling this concept more.With FIXT.1.1 since there is a separation between session and
application layer - an application protocol for FIXML payload could be
defined that would not include any FIX tags whatsoever - and list the
MsgType enumerations for the FIXML messages being transmitted.I see the value of FIXT.1.1 being outside of FIX not when used with FIX
tag=value application versions.
Hi Jim,
I was also wondering a little about this - does it make sense to put a little effort into developing a more formal approach for transferring non-FIX data over FIXT?
I was thinking something along the lines of mime types - it might make sense to register the different protocol types with IANA and then use a standard mime/content header in the payload…
Thoughts?
Cheers,
Russ
Mahesh - thanks for raising this issue again - I had forgotten this
discussion.I think the best way to communicate FIXML over FIX is to use FIXT.1.1
and use the XML_non_FIX (unfortunately named message) MsgType(tag
35)=‘n’.FIXT.1.1 is ideal for sending non-FIX or company proprietary messages
- I don’t know why we haven’t been selling this concept more.
With FIXT.1.1 since there is a separation between session and
application layer - an application protocol for FIXML payload could be
defined that would not include any FIX tags whatsoever - and list the
MsgType enumerations for the FIXML messages being transmitted.I see the value of FIXT.1.1 being outside of FIX not when used with
FIX tag=value application versions.Hi Jim,
I was also wondering a little about this - does it make sense to put a
little effort into developing a more formal approach for transferring
non-FIX data over FIXT?I was thinking something along the lines of mime types - it might make
sense to register the different protocol types with IANA and then use a
standard mime/content header in the payload…Thoughts?
Cheers,
Russ
Hi Russ,
We could use 95 RawDataLength and 96 RawData (Unformatted raw data, can include bitmaps, word processor documents, etc.) to transport MIME data. Presently 95 and 96 is only being used in Logon, these tags could be included in Message Type n and rename n XML_non_FIX to non_FIX
Regards,
Mahesh
Hi Russ,
We could use 95 RawDataLength and 96 RawData (Unformatted raw data, can
include bitmaps, word processor documents, etc.) to transport MIME data.
Presently 95 and 96 is only being used in Logon, these tags could be
included in Message Type n and rename n XML_non_FIX to non_FIXRegards, Mahesh
Hi Mahesh,
Sure, but I guess what I’m getting at is there is no tag to specify the actualy content-type of the message. I think we’d still need a message type that identifies the data block as mime content…
Cheers,
Russ
Hi Russ,
We could use 95 RawDataLength and 96 RawData (Unformatted raw data,
can include bitmaps, word processor documents, etc.) to transport
MIME data. Presently 95 and 96 is only being used in Logon, these
tags could be included in Message Type n and rename n XML_non_FIX
to non_FIXRegards, Mahesh
Hi Mahesh,
Sure, but I guess what I’m getting at is there is no tag to specify the
actualy content-type of the message. I think we’d still need a message
type that identifies the data block as mime content…Cheers,
Russ
Hi Russ,
You are right - A new message type to tell its a mime message, a new tag to identify the mime content type using the values listed under “Mime Types By File Extension” at
http://www.w3schools.com/media/media_mimeref.asp
and 95 RawDataLength and 96 RawData would contain the actual data itself.
Cheers,
Mahesh
Hi Russ,
You are right - A new message type to tell its a mime message, a new tag
to identify the mime content type using the values listed under “Mime
Types By File Extension” athttp://www.w3schools.com/media/media_mimeref.asp
and 95 RawDataLength and 96 RawData would contain the actual data
itself.Cheers, Mahesh
Hi Mahesh,
Right - actually, we wouldn’t even need a new tag, since the MIME type(s) can be specified in the actual payload, the same way they are in HTTP or in an email message. All this would take is to declare a MIME message type and, for the sake of formality, registering the various new types, like FIXML or FPML, with IANA as proper MIME types…
It’s a simple improvement, but I think this would add quite a bit to FIXT’s usefulness as a multi-purpose transport protocol for financial applications.
It’s a simple improvement, but I think this would add quite a bit to
FIXT’s usefulness as a multi-purpose transport protocol for financial
applications.
Hi Russ,
If MIME can be transported over FIXT, then it could find lot of other uses not only for financial applications, but outside of it, FIXT would be seen as TCP made 100% reliable with excellent recovery mechanisms. That could open up entirely new markets for FIX engines.
Are we planning on submitting a gap analysis to GTC for this new message type ?
Regards,
Mahesh
Hi Russ, Jim,
By adding a new enumerated tag to identify the content type, we can make 35=n transmit XML, MIME, RawData or other contents in the future by extending the enumeration.
The enumeration for this NewTag could be
1 - XML
2 - MIME
3 - RawData
When the value of NewTag = 1, then XMLDataLen(212) and XMLData(213) would become conditionally required.
When the value of NewTag = 2 or 3, then RawDataLength(95) and RawData(96) would become conditionally required. Based on this value the receiving application would know whether to parse RawData as MIME or RawData itself.
Being able to transmit RawData would be useful for integrators who want to replace a non FIX session which exchanges String messages with FIXT session which would not use FIX itself.
Regards,
K. Mahesh