[Http-crcsync] General comments on crcsync document

[Patrick McManus]

> Regarding trailing block and file-size header: we specify the file-size and we 
> (plan to) specify the number of blocks (though, it could indeed be implicitly 
> derived from the blocks-header-size like somebody mentioned).

so number of blocks is the missing information, not block-size?

Doesn't that still make the block size ambiguous?

e.g. file-size = 45, number of blocks = 3 .. 
wouldn't (3x15 + a trailer of 0) and (2x20 + a trailer of 5) both be
legitimate?

maybe I'm just missing something, but the block size would seem to be
something the server would need to compute hashes when looking for a
matched block.

I've also got this inkling that you ought to at least put some SHOULDs
around various recommended block sizes.. In the cases where the server
is not creating the resource completely on the fly this would allow it
to cache some important meta information and save itself some runtime
computations if it at least had a reasonable expectation about what
block size the next request would use...