[cifs-protocol] [EXTERNAL] Re: [MS-XCA] LZ77+ Huffman questions EOF/256 and decoded file length - TrackingID#2210140040006056

[Tom Jebo]

[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 2210140040006056 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: Friday, October 14, 2022 12:29 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>; cifs-protocol at lists.samba.org; Samuel Cabrero (Samba) <scabrero at samba.org>
Subject: [EXTERNAL] Re: [cifs-protocol] [MS-XCA] LZ77+ Huffman questions EOF/256 and decoded file length


There is also this paragraph, in "2.2.4 Processing", for which I would welcome any interpretive hints:

>> During the beginning of processing each block for decompression, an 
>> implementation MUST check for EOF. An implementation can do this by 
>> comparing the block size against the required space for a Huffman 
>> table — if this condition is met and all output has been written, 
>> then processing stops and success is returned. Alternately, an implementation can explicitly examine the input buffer using the Huffman table from the previous block.

I *think* (because "comparing the block size against the required space"; the term is not otherwise used in 2.2) "EOF" here is referring to the input running out.

But I have no explanation for the last sentence, unless it is implying that the decompressor can rely on all blocks being encoded with the same Huffman table. 
Is that correct? In some circumstances only?

I see the pseudo-code following this paragraph suggests a single table for the whole stream, rather than one per block, which is what is generally suggested elsewhere (e.g. the introductory remarks in 2.1).

cheers,
Douglas