How about the following wording? A SYN segment containing an ENO option MUST NOT include a TCP Fast Open (TFO) option [RFC7413]. However, TEPs MAY specify the use of data in SYN segments to achieve similar benefits to TFO.
The last TEP identifier suboption in host A's SYN segment is the _SYN TEP_. The SYN TEP governs the use of data in A's SYN segment. If the SYN TEP's specification does not define the use of such data, then host A's SYN segment MUST NOT contain data and host B MUST discard any such data. Host B must also discard data in A's SYN segment if either the SYN TEP differs from the negotiated TEP or host B disables encryption. The use of data in B's SYN-ACK segment is governed by the negotiated TEP. If the negotiated TEP's specification does not define the use of such data, then host B's SYN-ACK segment MUST NOT contain data and host A MUST discard any such data. Host A MUST also discard any received SYN data if it disables encryption. When a host discards SYN data, it MUST NOT acknowledge the sequence number of the discarded data. Rather, it MUST acknowledge the other host's initial sequence number as if the received SYN segment contained no data. Regardless of the SYN TEP and negotiated TEP, host A MUST NOT include data in a SYN-only segment when in mandatory application-aware mode. Moreover, in the event that host B is an active opener (because of simultaneous open), host B's SYN-only segment MUST NOT include data. Using data in SYN segments deviates from TCP semantics and can cause problems with middleboxes or non-compliant TCP hosts. Hence, all TEPs SHOULD support a normal mode of operation that does not make use of data in SYN segments. Moreover, implementations SHOULD employ SYN data only if explicitly requested by the application or in cases where such use is highly unlikely to pose problems. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
