> the fact that the server sends a close notification right before hanging up doesn’t help a client determine whether a particular stream just hasn’t finished

> the fact that the server sends a close notification right before hanging up doesn’t help a client determine whether a particular stream just hasn’t finished or is potentially infinite/undesireably large/hung instead of temporarily paused. Of course it does. The client receives close_notify and they know the stream is complete. If they don't get it, it wasn't. Simples. You're thinking of HTTP which does have this limitation (if not using an extension like chunked-transfer, multipart, or more popularly: TLS/https). > You have to “want” HTTP to apply some of the basic lessons in protocol design that we’ve learned over the last 70 years. Nonsense. > Sending payload sizes upfront (when available) is generally a great idea. There are lots of great ideas out there, but if you implement all of them you get the Homer-mobile. Do not let yourself worry so much about the goodness of the idea and instead think about what you get and how much it costs: Requiring fixed-length payloads would cost you streaming, whilst making them optional means you have to write both code to support them and code that tolerates their absence -- back where you started. To know whether or not it would be worth it you'd need to ask the Gemini users.