OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Bug in the bindings doc; wrong RFC


The SAML bindings document references RFC 1951.  This is wrong, it 
should be RFC 1950.  The difference is that 1951 is the "low level" 
compression format -- the actual "delate" method -- and 1950 is a 
wrapping mechanism around compression schemes such as deflate.

The text needs to be changed, and there MUST (sic) be a normative 
reference to RFC 1950 in the bibliography.  Note that the text uses the 
bracket notation, so I infer that this is just an editorial oversight.

Unfortunately, the fix has some impacts that the WG might want to 
evaluate.  Section 3.4.1.1 is titled the DEFLATE encoding, and the URN is
	urn:oasis:names:tc:SAML:2.0:bindings:URL-Encoding:DEFLATE

The issue is that RFC 1950 is officially known as the ZLIB Compressed 
Data Format, while RFC 1951 is the DEFLATE data format.  This means that 
the URN should probably change.  But I can imagine that the WG doesn't 
want to lose the neutral deflate term, and would also like to avoid the 
issue of eventual Redmond acceptance of a spec that references GNU 
software. :)  Perhaps "rfc1950" is a good choice for the URN trailer. On 
the third hand, ZLIB really is a neutral term that came from the PNG 
working group.

Part of the confusion is probably because of a bug in the Java 
documentation.  While java.util.zip.Deflator correctly indicates that it 
does ZLIB, java.util.zip.DeflatorOutputStream incorrectly references the 
"deflate" mechanism, and the same for the inflate side.  If you give an 
Inflator object an RFC 1951 stream, it throws an "unknown compression 
method" exception, as we saw at the SAML demo staging in DC last week. 
I'll leave it to someone with better contacts in the Java world to tell 
Sun. :)

The alternative is to declare that the spec is correct and that all the 
vendors at the SAML tech demo were wrong.  Or, more accurately, all the 
other ones. :)

	/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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]