Use ULEB64 encoding instead of RAW unsigned 64-bit fields for STRING lengths.

ULEB64 (https://en.wikipedia.org/wiki/LEB128) is a simple encoding where the 7th bit is used to show if there are more bytes following. So, lengths less than 128 can be encoded in one byte and so forth.

I doubt the protocol will routinely send lengths that are more than, say, four gigabytes. The longest ULEB64 number is eleven bytes, as far as I recall.

Other than that, I know nothing about the ancestors of the proposed protocol and thus cannot comment.

Is that true? I've never had use for it, but I've heard of people copying files from one machine to another with it and they seemed to think it worked well.

I do think there is room for improvement though. Not in the conceptual or logical HTTP/1.1 protocol, but in the physical over-the-wire implementation. I'd like to see a version of HTTP/1.1 designed to work with CBORS as the main over-the-wire format, possibly including support for CBORS over COAP.

Refining the ideas behind pasta, noodles, lasagna to create a simple dish for reliably ending hunger across the world. I came up with the unique name "french fries" all by myself!!1

(this document is a first draft, and is not intended to be implemented in its current form. But I am posting my trivial 5 minutes write-up with a click-bait title to Hackernews, anyway.)

What we need is an open-source Aspera. I gave it a shot a long time ago, but hammering the bugs out of something like that is really hard.

but in all seriousness this looks pretty interesting, definitely gonna check in again later :3