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

[Jeff McCashland (He/him)]

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