Reconciling example 7.1.10 with 4.3.1

[danjmarques]

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, the description of NextSeqNo states that it is "For re-establishment of a recoverable [see #70] flow only...".

It seem that one of these is in error: either the example in 7.1.10 should not have NextSeqNo set on the Establish message, or the description in 4.3.1 should say "For re-establishment of a recoverable or idempotent flow...".

If the schema in 4.3.1 needs to be changed, then the last paragraph in that section needs adjustment too: if the flow is idempotent, the server will not be sending RetransmitRequests (would it send NotApplied?). If those change are made to 4.3.1, then similar changes would need to be made with 4.3.2 as well.

[donmendelson]

In the example, NextSeqNo for Establishment of idempotent ClientFlow should be null.

[danjmarques]

For the sake of completeness, the change required for 7.1.10 (removing NextSeqNo from an Idempotent Establish message) needs to be made in a few other locations. These include 7.2.2-4, 7.3.1, 7.3.1.1-3, 7.3.4, 7.3.4.1, and 7.3.5.1-4.

Example 7.3.3 shows a similar issue where the Establish has a NewSeqNo, but in this case the client's flow is Unsequenced.

Examples 7.2.2-4 have a different typo, where the 2nd round of Establish and EstablishmentAck appear to have ClientFlow and ServerFlow values defined, even though those fields aren't defined for those messages.