> the focus should just be on good documentation and testing for running Avro RPC over arbitrary transports.
Yes, I agree, that's a good short-term focus. The spec currently defines the binary format of requests and responses. But to test compatibility of implementations we need a wire protocol. Rather than use a TCP socket-based protocl for this interoperability testing I think we're better off using HTTP for now, since it's well specified and has conforming implementations. The topic of this bug illustrates this: HTTP has explicit rules about keep-alive, while our not-yet-fully-specified TCP socket protocol does not. Our time is better spent, in the short-term, ensuring interoperability than fully-specifying a TCP socket protocol.
Long-term, our goal is to have a high-performance, standard wire protocol for Avro RPC, so that clients and services in different languages and from different institutions can interact. HTTP gives us a standard wire protocol, but there are concerns its performance, lack of multiplexing, and the appropriateness of its security. Until we develop a protocol that addresses these, we should only describe HTTP in the spec and we should use HTTP for interoperability testing, lest we end up with a hodge-podge of incompatible legacy protocols that folks might expect us to support forever.