On Wed, 28 Feb 2018 15:22:44 -0800
Brandon Williams [off-list ref] wrote:

I don't think we should use the term "half-duplex" - from a search, it
means that both parties can use the wire but not simultaneously, which
is not strictly true. Might be better to just say "see the documentation
for the stateless-connect command for more information".

+'stateless-connect' <service>::
+	Experimental; for internal use only.
+	Connects to the given remote service for communication using
+	git's wire-protocol version 2.  This establishes a stateless,
+	half-duplex connection.  Valid replies to this command are empty
+	line (connection established), 'fallback' (no smart transport
+	support, fall back to dumb transports) and just exiting with
+	error message printed (can't connect, don't bother trying to
+	fall back).  After line feed terminating the positive (empty)
+	response, the output of the service starts.  Messages (both
+	request and response) must be terminated with a single flush
+	packet, allowing the remote helper to properly act as a proxy.
+	After the connection ends, the remote helper exits.
++
+Supported if the helper has the "stateless-connect" capability.

I'm not sure of the relevance of "allowing the remote helper to properly
act as a proxy" - this scheme does make it easier to implement proxies,
not for any party to start acting as one instead. I would write that
part as:

    Messages (both request and response) must consist of zero or more
    PKT-LINEs, terminating in a flush packet. The client must not expect
    the server to store any state in between request-response pairs.

(This covers the so-called "half-duplex" part and the "stateless" part.)