Martin,
On Feb 25, 2014, at 2:07 PM, Michael Sweet <msweet@apple.com> wrote:
> Martin,
>
> On Feb 25, 2014, at 1:31 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>> On 25 February 2014 10:27, Michael Sweet <msweet@apple.com> wrote:
>>> That's a good (but unfortunate) point, and one that has also caused
>>> interoperability problems for IPP which normatively ties "deflate" to RFC
>>> 1951 (raw deflate) and not to RFC 1950 (zlib format) like HTTP/1.1 does...
>>> :/
>>
>> That's an interesting point. Are you suggesting that IPP is
>> intentionally divergent from HTTP/1.1? If so, can you explain why
>> that choice was made?
>
> I'd have to check the old mailing list logs from 1998, but I think it wasn't intentional but a mistake based on the compression keyword values (none, compress, deflate, gzip) - the same sort of mistake that's been made by HTTP implementors due to the unfortunately confusion between zlib the format and deflate the encoding name being used when zlib is meant.
OK, found out the source of this reference; it appears to have come from IPP/1.1 LC comments made by Ned Freed:
http://www.pwg.org/archives/ipp/2000/009237.html
In it I found the following comment:
Section 4.4.32. GZIP references RFC 1952 which is fine, but why doesn't
deflate reference RFC 1951?
TH> Fixed.
FWIW, the previous IPP/1.0 RFC (2566) did not have references for 'deflate' or 'compress'.
So it looks like this is a 14-year-old editorial choice/mistake that we are stuck with in IPP...
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair