[cifs-protocol] [EXTERNAL] [MS-XCA] LZ77+ Huffman example 1 - TrackingID#2210140040005999
Jeff McCashland (He/him)
jeffm at microsoft.com
Thu Oct 27 20:17:58 UTC 2022
Thank you for the update. I'll look into that aspect.
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
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
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 188.8.131.52 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.
More information about the cifs-protocol