unentangle resumable uploads from streamable transfers

proposals/4016-streaming-e2ee-file-transfer.md

@@ -162,14 +162,18 @@ protocol "Registration Code (0xFFFFFFF):32,Block sequence number:32,Encrypted bl
 
 ```
 
-The actual file upload can then be streamed in blocks to the media server using `Content-Range` headers on the `PUT`
-method as https://developers.google.com/youtube/v3/guides/using_resumable_upload_protocol#Resume_Upload.
+The actual file upload can then be streamed in the request body in the PUT (requires HTTP/2 in browsers). Similarly, the
+download can be streamed in the response body.  The download should stream as rapidly as possible from the media
+server, letting the receiver view it incrementally as the upload happens, providing "zero-latency" - while also storing
+the stream to disk.
 
-TODO: the media API needs to advertise that it supports streamed file transfer somehow.
+For resumable uploads (or to upload in blocks for HTTP clients which don't support streaming request bodies), the client
+can use `Content-Range` headers as per https://developers.google.com/youtube/v3/guides/using_resumable_upload_protocol#Resume_Upload.
 
-We then use normal [HTTP Range](https://datatracker.ietf.org/doc/html/rfc2616#section-14.35.1) headers to seek and
-resume while downloading.  The actual download should stream as rapidly as possible from the media server, letting the
-receiver view it incrementally as the upload happens, providing "zero-latency".
+TODO: the media API needs to advertise if it supports resumable uploads.
+
+For resumable downloads, we then use normal [HTTP Range](https://datatracker.ietf.org/doc/html/rfc2616#section-14.35.1) headers to seek and
+resume while downloading.
 
 TODO: We need a way to mark a transfer as complete or cancelled (via a relation?).  If cancelled, the sender should
 delete the partial upload (but the partial contents will have already leaked to the other side, of course).