Distinguish 200 acceptance from a 522 protocol error

A protocol-support reply is not a file transfer or permission to connect anywhere.

• This is a three-machine proxy FTP fixture, not the ordinary same-two-machine case that §4 requires to use EPSV. B’s listening endpoint was obtained separately; file-operation authorization and B’s receiving setup are assumed.
• Upon a valid EPRT command the server MUST return 200. If the requested network protocol is unsupported, 522 identifies that failure. Its text MUST contain a parenthesized comma-separated list of supported family numbers.
• The human text before the 522 protocol list MUST NOT contain parentheses and SHOULD explain that the requested protocol is unsupported. Example: 522 Network protocol not supported (1). The final period here is prose, not a reply byte.
• The negative and positive replies shown are separate server-support cases. A 200 setup acknowledgement alone does not move file bytes. The selected successful branch later uses an authorized RETR at A, with B already prepared to receive, before the A-to-B data connection/file flow.
• RFC 2577 §§2–3 discusses FTP bounce abuse and server policy. Merely naming B in EPRT does not prove B’s identity or authorize a third-party connection; these extensions are not an encryption or authentication mechanism.

Documentation addresses and chosen listening ports. Each chapter is a separate bounded example; FTP authentication, authorization, file commands and transfer replies are not a complete FTP implementation here. EPRT/EPSV provide no encryption or guaranteed reachability.