Re: [security-services] Bug in the bindings doc; wrong RFC

[Rich Salz <rsalz@datapower.com>]

> It may be that use with most libraries would require 1950/zlib and that
> referencing DEFLATE isn't sufficient to specify the wire format.

Either it's DEFLATE (RFC 1951) or its ZLIB (RFC 1950).  ZLIB is a 
wrapper (header and trailer) around compressed data, and is currently 
only defined for DEFLATE.  There are probably libraries that can 
transparently consume either format, but I can't imagine how to 
implement one that magically knows which one to generate. :)

 > The point
> was to avoid formats like gzip that presumed a lot of metadata about the
> stream that was N/A to this use case.

That makes complete sense.  (I didn't mention RFC 1952, and I don't see 
anyone else doing so either.)

> If the DEFLATE scheme is itself enough to be "descriptive", then the spec,
> IMHO, is correct. It may be that using zlib instead is preferable, and an
> alternate encoding could be developed for that.

If DEFLATE/RFC1951 is what was intended, and what is still desired, then 
the specification is correct, although it is missing a bibliography 
entry for the actual RFC.

I will point out, however, that everyone seems to have implemented it 
wrong.  Let me emphasize that:  everyone. Certainly, some of this is the 
fault of errors in the Java documentation.  But it also has to make you 
wonder if the spec itself doesn't, somehow, need improvement.

It is unfortunate that the evil triumvirate (RFC 195[012]) didn't 
include any test vectors.
	/r$

-- 
Rich Salz, Chief Security Architect
DataPower Technology                           http://www.datapower.com
XS40 XML Security Gateway   http://www.datapower.com/products/xs40.html
XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html