[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cifs-protocol
Subject:    Re: [cifs-protocol] [EXTERNAL] Re: [MS-XCA] LZ77+ Huffman questions EOF/256 and decoded file length 
From:       Obaid Farooqi via cifs-protocol <cifs-protocol () lists ! samba ! org>
Date:       2022-10-18 19:43:41
Message-ID: MN2PR21MB13907AE348C56730055BFF65C6289 () MN2PR21MB1390 ! namprd21 ! prod ! outlook ! com
[Download RAW message or body]

[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@microsoft.com> 
Sent: Friday, October 14, 2022 11:50 AM
To: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>; cifs-protocol@lists.samba.org; \
                Samuel Cabrero (Samba) <scabrero@samba.org>
Cc: Microsoft Support <supportmail@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@catalyst.net.nz> 
Sent: Friday, October 14, 2022 12:29 AM
To: Interoperability Documentation Help <dochelp@microsoft.com>; \
                cifs-protocol@lists.samba.org; Samuel Cabrero (Samba) \
                <scabrero@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

_______________________________________________
cifs-protocol mailing list
cifs-protocol@lists.samba.org
https://lists.samba.org/mailman/listinfo/cifs-protocol


[prev in list] [next in list] [prev in thread] [next in thread]