"Used in message section" shows different MesgTypes in FIXT.1.1 and FIX.5.0SP2 for Tag 96 (RawData)

, ,
1

Imported from previous forum

2

http://fixprotocol.org/FIXimate3.0/en/FIX.5.0SP2/tag96.html

shows [Email] [Logon] [News] [UserRequest]

http://fixprotocol.org/FIXimate3.0/en/FIXT.1.1/tag96.html

shows [Logon] only

3

Do you see why this is the correct behavior? Think about FIXT - it is the session layer only and is supposed to have no knowledge of the application layer.

http://fixprotocol.org/FIXimate3.0/en/FIX.5.0SP2/tag96.html

shows [Email] [Logon] [News] [UserRequest]

http://fixprotocol.org/FIXimate3.0/en/FIXT.1.1/tag96.html

shows [Logon] only

4

Hi Jim,

To complete this, should FIX.5.0SP2 NOT show [Logon]?

As that is is session layer not application layer?

Clive

Do you see why this is the correct behavior? Think about FIXT - it is the session layer only and is supposed to have no knowledge of the application layer.

http://fixprotocol.org/FIXimate3.0/en/FIX.5.0SP2/tag96.html

shows [Email] [Logon] [News] [UserRequest]

http://fixprotocol.org/FIXimate3.0/en/FIXT.1.1/tag96.html

shows [Logon] only

5

Good point Clive.

This was one of the fields which failed to load when I was loading FIXT.1.1 and FIX.5.0 repositories together and my hand edited merged repository had these fields in all four [Email] [Logon] [News] [UserRequest] message types.

Regards,
Mahesh

Hi Jim,

To complete this, should FIX.5.0SP2 NOT show [Logon]?

As that is is session layer not application layer?

Clive

Do you see why this is the correct behavior? Think about FIXT - it is the session layer only and is supposed to have no knowledge of the application layer.

http://fixprotocol.org/FIXimate3.0/en/FIX.5.0SP2/tag96.html

shows [Email] [Logon] [News] [UserRequest]

http://fixprotocol.org/FIXimate3.0/en/FIXT.1.1/tag96.html

shows [Logon] only

6

Eventually you are correct. Right now as we only have one session layer for FIX.5.0 through FIX.5.0SP2 - we have left the repository consolidated. If the only think today that can be used is FIXT.1.1+FIX.5.0, FIXT.1.1+FIX.5.0SP1, etc. Why separate the repository right now. However, FIXT.1.1 can be used to communicate other payload besides FIX so it needs to be represented stand alone.

It looks like FIXT.1.2 will be released in the near future and then we have to resume the work we started on configuring a session layer plus a n application layer.

Hi Jim,

To complete this, should FIX.5.0SP2 NOT show [Logon]?

As that is is session layer not application layer?

Clive

Do you see why this is the correct behavior? Think about FIXT - it is the session layer only and is supposed to have no knowledge of the application layer.

http://fixprotocol.org/FIXimate3.0/en/FIX.5.0SP2/tag96.html

shows [Email] [Logon] [News] [UserRequest]

http://fixprotocol.org/FIXimate3.0/en/FIXT.1.1/tag96.html

shows [Logon] only

7

Jim,

Can I have any documents related to FIXT.1.2 changes.

Regards,
K. Mahesh

Eventually you are correct. Right now as we only have one session layer for FIX.5.0 through FIX.5.0SP2 - we have left the repository consolidated. If the only think today that can be used is FIXT.1.1+FIX.5.0, FIXT.1.1+FIX.5.0SP1, etc. Why separate the repository right now. However, FIXT.1.1 can be used to communicate other payload besides FIX so it needs to be represented stand alone.

It looks like FIXT.1.2 will be released in the near future and then we have to resume the work we started on configuring a session layer plus a n application layer.

8

Mahesh,

Look for the CME system identifier and the NGM logon proposal.

In addition to requiring ApplVerID on each message to simplify maintenance of state.

Jim,

Can I have any documents related to FIXT.1.2 changes.

Regards,
K. Mahesh

Eventually you are correct. Right now as we only have one session layer for FIX.5.0 through FIX.5.0SP2 - we have left the repository consolidated. If the only think today that can be used is FIXT.1.1+FIX.5.0, FIXT.1.1+FIX.5.0SP1, etc. Why separate the repository right now. However, FIXT.1.1 can be used to communicate other payload besides FIX so it needs to be represented stand alone.

It looks like FIXT.1.2 will be released in the near future and then we have to resume the work we started on configuring a session layer plus a n application layer.

9

Hi Jim,

What about approved proposals at

http://fixprotocol.org/committees/gtc/documents

When is the last date for submission of Gap Analysis / Proposal to GTC for inclusion in FIXT.1.2 release after discussion / approval of GTC ?

Regards,
K. Mahesh

Mahesh,

Look for the CME system identifier and the NGM logon proposal.

In addition to requiring ApplVerID on each message to simplify maintenance of state.

Jim,

Can I have any documents related to FIXT.1.2 changes.

Regards,
K. Mahesh

Eventually you are correct. Right now as we only have one session layer for FIX.5.0 through FIX.5.0SP2 - we have left the repository consolidated. If the only think today that can be used is FIXT.1.1+FIX.5.0, FIXT.1.1+FIX.5.0SP1, etc. Why separate the repository right now. However, FIXT.1.1 can be used to communicate other payload besides FIX so it needs to be represented stand alone.

It looks like FIXT.1.2 will be released in the near future and then we have to resume the work we started on configuring a session layer plus a n application layer.