fixp-specification

fixp-specification copied to clipboard

An Establish request may be rejected with a reason of AlreadyEstablished. However, there is no explicit error code for a redundant Negotiate. Suggest adding AlreadyNegotiated to NegotiationRejectCode. Also, the spec...

donmendelson

Sequence formation Establish vs EstablishmentAck

2

Section 7.3.1.1 states that > "The Sequence, Context, EstablishmentAck and Retransmission messages are sequence forming. They turn the message flow into a sequenced mode since they have the next implicit...

danjmarques

Question re. example 7.3.1.1

1

In example 7.3.1.1, the client sends a NewOrderSingle with (implicit) sequence number of 100, which the server presumably responds to. The client then sends a Sequence message setting the NextSeqNo...

danjmarques

Reconciling example 7.1.10 with 4.3.1

2

In example 7.1.10, the Negotiate message specifies that the ClientFlow is "Idempotent". The subsequent Establish message has NextSeqNo set to "1". In 4.3.1, in the schema/table for the Establish message,...

danjmarques

Correct example to reconcile 4.6.2.2 with 7.3.4.2

6

Reading the example in #42, where there is RetransmitRequest FromSeqNo=1000 Count=20 Retransmission FromSeqno=1000 Count=5, followed by 5 application messages Would it be correct for the re-transmitting side to issue Retransmission...

danjmarques

V 1.1 Draft Standard - Issue with 4.3.1's table

1

I believe that the table describing the Establish message in table 4.3.1 has an error: The "Description" field for the NextSeqNo should be "For re-establishment of a recoverable **client** flow...

danjmarques

V 1.1 Draft Standard Usage Example 7.1.4

1

I believe that the "Server Flow" value in the 7.1.4 table should be "Recoverable"

danjmarques

Out of Band Recovery

6

To facilitate out of band recovery for previously used UUID's we might need to enhance the RetransmitRequest to add an additional field such as OnBehalfOfSessionID since we cannot expect the...

adkapur