[cifs-protocol] [EXTERNAL] [MS-XCA] LZ77+ Huffman example 1 - TrackingID#2210140040005999

[Jeff McCashland (He/him)]

Hi Douglas,

The 4 zero bytes are the encoding of the EOF. We don't actually decode these bytes. Once we decode the final literal 'z', we realize we've reached the original uncompressed size, and stop processing. This is why it's essential to pass in the correct size of the original uncompressed buffer. 

Let me know if that doesn't fully answer your question. 

Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team 
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada)
Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300

-----Original Message-----
From: Jeff McCashland (He/him) 
Sent: Thursday, October 27, 2022 1:18 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] [MS-XCA] LZ77+ Huffman example 1 - TrackingID#2210140040005999

Hi Douglas,

Thank you for the update. I'll look into that aspect. 

Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300

-----Original Message-----
From: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>
Sent: Thursday, October 27, 2022 1:09 PM
To: Jeff McCashland (He/him) <jeffm at microsoft.com>; cifs-protocol at lists.samba.org; Samuel Cabrero (Samba) <scabrero at samba.org>
Cc: Microsoft Support <supportmail at microsoft.com>
Subject: Re: [EXTERNAL] [MS-XCA] LZ77+ Huffman example 1 - TrackingID#2210140040005999

hi Jeff,

I would like to amend his question slightly if I may.

> In the first example in Section 3.2, where 
> "abcdefghijklmnopqrstuvwxyz" is "compressed" into a ~282 byte sequence 
> ending with
> 
> d8 52 3e d7 94 11 5b e9 19 5f f9 d6 7c df 8d 04 00 00 00 00
> 
> where do all the trailing zeros come from?
> 
> They do not encode characters, and from the decoding description in 
> 2.2.4, we don't read 32 bits at a time except at the start of the 
> first block, so processing should be well finished before we get to 
> read these. It seems to violate the "input buffer is finished" termination rule.
> 

I now think I understand how the zeroes are produced, based on the interactions between  OutputPosition1, OutputPosition2, and OutputPosition in the 2.1.4.3 pseudocode. I can reproduce the result.

But I still can't understand how they are consumed, based on the terminating conditions in the decoding phase (2.2.4). So the "where do they come from" part of the question is answered, but the implicit "how are they read" part is not.

Douglas