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

[Douglas Bagnall]

Thanks Obaid,

That answers the question well and makes sense.

cheers,
Douglas


On 29/11/22 07:07, Obaid Farooqi wrote:
> Hi Douglas:
> After spending a lot of time researching this, I have not seen any instance in code where the following behavior is implemented:
> "
> Alternately, an implementation can explicitly examine the input buffer using the Huffman table from the previous block.
> "
> 
> For the following excerpt:
> "
> 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.
> "
> Here is what the code is doing at the very beginning of every Huffman block:
> 
> If (the input buffer size is less than 260 bytes)
> {
> If (output position is equal to output end)
> {
>   Return success
> }
> 
> Return STATUS_BAD_COMPRESSION_BUFFER;
> 
> }
> 
> I'll file a bug to fix the document.
> 
> Please let me know if this does not answer your question.
> 
> Regards,
> Obaid Farooqi
> Escalation Engineer | Microsoft
> 
> -----Original Message-----
> From: Obaid Farooqi
> Sent: Tuesday, October 18, 2022 2:44 PM
> To: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>; cifs-protocol at lists.samba.org; Samuel Cabrero (Samba) <scabrero at samba.org>
> Cc: Microsoft Support <supportmail at microsoft.com>
> Subject: RE: [EXTERNAL] Re: [cifs-protocol] [MS-XCA] LZ77+ Huffman questions EOF/256 and decoded file length - TrackingID#2210140040006056
> 
> [Tom to Bcc]
> Hi Douglas:
> I'll help you with this issue and will be in touch as soon as I have an answer.
> 
> Regards,
> Obaid Farooqi
> Escalation Engineer | Microsoft
> 
> -----Original Message-----
> From: Tom Jebo <tomjebo at microsoft.com>
> Sent: Friday, October 14, 2022 11:50 AM
> To: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>; cifs-protocol at lists.samba.org; Samuel Cabrero (Samba) <scabrero at samba.org>
> Cc: Microsoft Support <supportmail at microsoft.com>
> Subject: RE: [EXTERNAL] Re: [cifs-protocol] [MS-XCA] LZ77+ Huffman questions EOF/256 and decoded file length - TrackingID#2210140040006056
> 
> [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
>