Comment by kabdib
12 years ago
This gets a surprising number of things right. I've worked on a couple of these. In particular I'm delighted to see both the definite and indefinite streams of things.
I'm a little bit tired (well, more than a little tired) of standards that aren't couched in terms that are directly executable. English descriptions and psuedo-code are fine, but in the end I want to have some working code that implements an API for the stuff. Doesn't have to be an official API, but something usable shows me that (a) it is indeed usable, and (b) will go a long way towards heading off other people's mistakes.
We don't do crypto without test vectors. I don't know why we think we can do other complex standards without test vectors, either. (I worked on NBS / NIST in the 70s on some verification suites. Have we lost that practice?)
I think that much of what is busted on the modern web can be traced back to loose english and lack of reference code (even stuff with placeholders). CSS, HTML, etc., I'm looking at you... :-/
> In particular I'm delighted to see both the definite and indefinite streams of things.
Why? I can see the advantages of either one, but I don't see what having both gets you.
In my experience the implementation advantages of having length-prefixed lists disappear if you have to support indefinite lengths anyway.
I want to use the same data structures for
- Passing small messages around
- Doing streaming of large content (occasionally)
I'm probably doing these over different pipes, but the data shares a lot of the same characteristics and I don't want to use two totally different APIs to get the job done.
"Large" can be "I need to transfer something on the order of megabytes using a 4K intermediate buffer."