Re: [hybi] Restarting IESG review on permessage-deflate

[Tobias Oberstein <[e-mail]>]

>>Lets collect a list: a) stuff that exposes the complete zlib vs b) 
>>stuff that does not;)
>>
>>a) C, C++, Python, NodeJS, Perl, Ruby, PHP, Erlang, Haskell
>>b) Java

>If you have an environment to develop application in C then it should be relatively easy to compile the zlib library and link it to your program, but the C language and its standard library and the typical extensions to it do not usually include zlib by themself; and if you >write in Java, there are comparable libraries available where the same holds true, but the out-of-the-box experience is different. So this does not seem to be a fair comparison.

Of course making up such lists is questionable.

My main point is: should IETF protocols be designed against a least-common denominator of todays existing language run-times / implementations / environments? I don't know if there is a general IETF policy with this. My view: it should not.

>A better comparison would be among independent DEFLATE implementations; that way we could at least tell how zlib-specific the relevant features are, and if they are very zlib-specific and not commonly implemented in independent implementations, they might >make bad mandatory features. My http://bjoern.hoehrmann.de/pngwolf/ for instance uses the DEFLATE imple- mentation in Igor Pavlov's 7-Zip library, which I believe is the best- compressing free software implementation; that would be a good candiate, among >others.

Good point. It's one thing which run-time does expose which feature of one and the same Deflate implementation ("zlib"), and another to compare features of independent Deflate implementations.

Here is another point:

The current spec only refers to the original LZ77 paper under normative-references:

http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-12#page-27

The Deflate RFC

http://tools.ietf.org/html/rfc1951

is only listed under informational.

This is strange, since the "permessage-deflate" extension is not only LZ77, but really Deflate (= LZ77 + Huffman Coding + Window Size .. see below).

And the RFC1951 mentions:

" 3.3. Compliance

      A compressor may limit further the ranges of values specified in
      the previous section and still be compliant; for example, it may
      limit the range of backward pointers to some value smaller than
      32K.  Similarly, a compressor may limit the size of blocks so that
      a compressible block fits in memory.
"

Which I read as refering to "window size". But the wording neither has SHOULD nor MUST in it.

Mmh.

/Tobias