[cifs-protocol] [EXTERNAL] [MS-XCA] LZ77+ Huffman: questions about blocks - TrackingID#2210140040006030

Tom Jebo tomjebo at microsoft.com
Fri Oct 14 16:45:23 UTC 2022

[dochelp to bcc]
[casemail cc]

Hi Douglas, 

Thank you for your request. One of the Open Specifications team will respond to start working with you. I have created case 2210140040006030 and added the number to the subject of this email. Please refer to this case number in future communications regarding this issue.

Best regards,
Tom Jebo
Sr Escalation Engineer
Microsoft Open Specifications

-----Original Message-----
From: Douglas Bagnall <douglas.bagnall at catalyst.net.nz> 
Sent: Thursday, October 13, 2022 9:57 PM
To: Interoperability Documentation Help <dochelp at microsoft.com>; cifs-protocol at lists.samba.org; Samuel Cabrero (Samba) <scabrero at samba.org>
Subject: [EXTERNAL] [MS-XCA] LZ77+ Huffman: questions about blocks

hi Dochelp,

Does the beginning of the second and subsequent blocks break the bitstream, starting again at a byte boundary after the new Huffman table?

The question is best explained by analogy to the way long lengths are handled in matches. Suppose we have a match symbol in the middle of a bitstream, and the match is a long one, requiring the reading of an extra byte:

    ijklmnop  abcDEFgh [distance] qrs...
                 [match 1, 15]

Here abc, ghi.. are the sequence of bits in the stream around the match DEF, which is read in alternating bytes by little-endian rules, and the distance is plonked in the middle of the stream as an individual byte. The stream just flows around it, so gh-ijklmnop are interpreted after [distance].

Now, if DEF instead ended the block:

    ijklmnop  abcDEFgh [new Huffman table] qrs...
                 [ends the block (64k)]

would the bits gh-jklmnop be interpreted using the new Huffman table, as part of the new block, or would those bits be dropped?

Multi-block examples would of course be helpful.


More information about the cifs-protocol mailing list