Thanks Douglas, I'll go ahead and close this one out. Happy New Year!
Regards, Kristian Smith Escalation Engineer | Microsoft(r) Corporation Email: [email protected] -----Original Message----- From: Douglas Bagnall <[email protected]> Sent: Tuesday, January 13, 2026 5:29 PM To: Kristian Smith <[email protected]> Cc: Microsoft Support <[email protected]>; [email protected] Subject: Re: [EXTERNAL] is MS-DRSR 4.1.10.5.21 CompressOrDecompressWin2k3 the same as MS-WUSP 2.1.1.1 CompressOrDecompressWin2k3 ? - TrackingID#2512240040003184 hi Kristian, Thank you. I have no further questions. Douglas On 14/01/2026 13:56, Kristian Smith wrote: > Hi Douglas, > > They are parallel implementations of the same functionality. Essentially > separate source, but same design. Hope that helps. > > Regards, > Kristian Smith > Escalation Engineer | Microsoft(r) Corporation > Email: [email protected] > > -----Original Message----- > From: Douglas Bagnall <[email protected]> > Sent: Tuesday, January 13, 2026 4:52 PM > To: Kristian Smith <[email protected]> > Cc: Microsoft Support <[email protected]>; > [email protected] > Subject: Re: [EXTERNAL] is MS-DRSR 4.1.10.5.21 CompressOrDecompressWin2k3 the > same as MS-WUSP 2.1.1.1 CompressOrDecompressWin2k3 ? - > TrackingID#2512240040003184 > > hi Kristian, > > I am still interested to know whether they are exactly the same or not. > > thanks > Douglas > > > On 14/01/2026 13:38, Kristian Smith wrote: >> Hi Douglas, >> >> I reached out to the engineering team and we determined that the >> discrepancies are in MS-DRSR. MS-DRSR should reflect " a match length of up >> to 65,535 bytes + 3 bytes" as well as " This scheme is good for lengths of >> up to 279". I've submitted a bug against the document and you should see >> this updated in a future document release. >> >> Thank you for helping us keep the docs up to date. Please let me know if you >> have any further questions. >> >> Regards, >> Kristian Smith >> Escalation Engineer | Microsoft(r) Corporation >> Email: [email protected] >> >> -----Original Message----- >> From: Tom Jebo <[email protected]> >> Sent: Wednesday, December 24, 2025 8:57 AM >> To: Douglas Bagnall <[email protected]>; >> [email protected] >> Cc: Interoperability Documentation Help <[email protected]>; Microsoft >> Support <[email protected]> >> Subject: RE: [EXTERNAL] is MS-DRSR 4.1.10.5.21 CompressOrDecompressWin2k3 >> the same as MS-WUSP 2.1.1.1 CompressOrDecompressWin2k3 ? - >> TrackingID#2512240040003184 >> >> [dochelp to cc] >> [support mail to cc] >> >> Hi Douglas, >> >> Thanks for your request regarding MS-DRSR 4.1.10.5.21 and MS-WUSP 2.1.1.1. >> One of the Open Specifications team members will respond to assist you. In >> the meantime, we've created case 2512240040003184 to track this request. >> Please leave the case number in the subject when communicating with our team >> about this request. >> >> Best regards, >> Tom Jebo >> Microsoft Open Specifications Support >> >> -----Original Message----- >> From: Douglas Bagnall <[email protected]> >> Sent: Tuesday, December 23, 2025 3:40 PM >> To: Interoperability Documentation Help <[email protected]>; >> [email protected] >> Subject: [EXTERNAL] is MS-DRSR 4.1.10.5.21 CompressOrDecompressWin2k3 the >> same as MS-WUSP 2.1.1.1 CompressOrDecompressWin2k3 ? >> >> hi Dochelp. >> >> The MS-DRSR and MS-WUSP definitions of CompressOrDecompressWin2k3 look very >> similar. >> Are they really the same procedure? >> >> If they are in fact the same, my next question is which document is most >> correct. >> I haven't looked closely, but I see these differences: >> >> MS-WUSP: This scheme is good for lengths of up to 279 >> MS-DRSR: This scheme is good for lengths of up to 278 >> >> MS-WUSP: a match length of up to 65,535 bytes + 3 bytes >> MS-DRSR: a match length of up to 32,768 bytes + 3 bytes >> >> Perhaps one has been updated and not the other? >> >> >> In November 2022[1] I asked if MS-XCA 2.3 and 2.4 "Plain LZ77" was the same >> as the MS-DRSR procedure. The answer was "MS-DRSR uses a different API than >> what MS-XCA uses", which I took to mean that even if it was initially >> intended that they were the same, they could easily be accidentally >> different. I guess my first question could be answered in the same way -- >> are these using the same shared library function? >> >> [1] https://lists.samba.org/archive/cifs-protocol/2022-November/003902.html >> >> cheers, >> Douglas >> > _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
