[This message was posted by Mahesh Kumaraguru of <kay_mah...@yahoo.com> 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/98590df6 - PLEASE DO NOT REPLY BY MAIL.]
> > 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 [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.
