ZIP version used for OPC

Wed Jan 30 00:00:25 CET 2019

Alfred

You might find it helpful to chat to Alex Brown, Convenor of SC 34/WG 8, who was Project Editor for ISO/IEC 21320-1 Document Container File – Part 1: Core. He and Rex were involved in collaboration between SC 34 and PKWARE on defining a standard profile of ZIP for use in possible future packaged document formats, and I’m sure that Alex would have some interesting insights into areas for possible improvement of the standard ZIP format in ways that wouldn’t breach any of PKWARE’s IPR. Unfortunately, Alex won’t be in Milan, but I’m sure you could communicate with him remotely.

Kind regards,

Francis

From: caroline arms <caroline.arms at gmail.com> 
Sent: 29 January 2019 22:20
To: Alfred Hellstern <Alfred.Hellstern at microsoft.com>
Cc: Murata <eb2m-mrt at asahi-net.or.jp>; SC 34 WG4 <e-SC34-WG4 at ecma-international.org>; Rex Jaeschke <rex at rexjaeschke.com>; Rich McLain <richmc at microsoft.com>
Subject: Re: ZIP version used for OPC

Alfred,

"Public domain" is a copyright term and applies only to the document (the APPNOTE.TXT document).  Compression algorithms can covered by patents and thus subject to licenses.

As to the choice of ZIP, that was certainly made by Microsoft itself, probably long before any current members of WG4 were involved with OOXML.  You might see if someone from the Office team who was around back then might help you get the early history.

Rex and I were involved in the Ecma standardization process, although I only joined the working group fairly late in the process.  What I remember about ZIP from then is that at that point, PKWARE brought out a new APPNOTE.TXT with every change and stopped providing access to old versions.  Jean Paoli, or someone else in the Microsoft OOXML team, talked to PKWARE and got them to agree to leave a copy of the version of APPNOTE.TXT used in OOXML ( and indeed by the Open Document Format) available.  I was involved in a related effort, to get copies of all old versions available at the Library of Congress.  See https://www.loc.gov/preservation/digital/formats/intro/specifications.shtml .  As a result of these discussions, PKWARE made a decision to change its strategy and does now make old versions  available on its website.  A couple of those files are actually ones I retrieved from the Internet Archive and sent to PKWARE.

[Aside:  The same page has links to the specs for the binary Office formats.  That was requested by Jean Paoli as a step to make sure that Microsoft was making those specs available somewhere trusted.]

I hope that helps a bit.

      Caroline

On Tue, Jan 29, 2019 at 4:48 PM Alfred Hellstern <Alfred.Hellstern at microsoft.com <mailto:Alfred.Hellstern at microsoft.com> > wrote:

Thanks Murata-san. Are you saying that if WG4 were to make a normative reference to a newer version of the ZIP format, we’d be forcing implementers to pay licensing fees to PKWare?

However, in the Wikipedia topic on PKWare, I find the following:

PKZIP was the first program to use the new  <https://en.wikipedia.org/wiki/ZIP_(file_format)> ZIP file format, which Katz developed in conjunction with Gary Conway and subsequently released into the public domain. PKWARE grew rapidly in its early years, fueled by enthusiasm from the bulletin board and shareware communities, along with steady business from large corporations who were eager to minimize the demands on their limited computing resources. <https://en.wikipedia.org/wiki/PKWare#cite_note-wsjkatz-1> [1] The .ZIP format proved so popular that it became the de facto standard for data compression and remains in use throughout the world after more than 30 years.

…

In addition to its data compression and encryption products, PKWARE continues to maintain the .ZIP file format standard in the public domain. The company publishes an Application Note on the .ZIP file format, providing developers a general description and technical details of the .ZIP file storage specification. <https://en.wikipedia.org/wiki/PKWare#cite_note-APP_Note-7> [7] This Application Note ensures continued interoperability of the .ZIP file format for all users. (https://en.wikipedia.org/wiki/PKWare)

If it’s public domain, doesn’t that mean “no licensing fees”?

Do you or anyone have a bit more history on when and why ZIP was chosen, and how the licensing aspect was dealt with back then?

Thanks

ALfred

From: MURATA Makoto <eb2m-mrt at asahi-net.or.jp <mailto:eb2m-mrt at asahi-net.or.jp> > 
Sent: Thursday, January 24, 2019 8:39 PM
To: Alfred Hellstern <Alfred.Hellstern at microsoft.com <mailto:Alfred.Hellstern at microsoft.com> >
Cc: SC 34 WG4 <e-SC34-WG4 at ecma-international.org <mailto:e-SC34-WG4 at ecma-international.org> >; caroline arms <caroline.arms at gmail.com <mailto:caroline.arms at gmail.com> >; Rex Jaeschke <rex at RexJaeschke.com <mailto:rex at RexJaeschke.com> >; Rich McLain <richmc at microsoft.com <mailto:richmc at microsoft.com> >
Subject: Re: ZIP version used for OPC

Alfred,

First, I strongly think that digital signatures of OPC have

to be significantly extended. XAdES EN, XML DSig 1.1, and

SHA 256 are strongly required.  But WG4 has agreed not to

do so in this revision.  One reason is that the revision of

ISO 14533-2:2012 (XAdES Profile) has not been completed

yet.  After the current revision of OPC is completed, I

hope to start an amendment project for digital signatures.

Second, it is not only OPC that uses DEFLATE and 

nothing else.  EPUB does the same thing.  I believe 

that other compression methods as documented in 

PKWARE Appnote require license fee to PKWARE.

Regards,

Makoto

2019年1月25日(金) 6:08 Alfred Hellstern <Alfred.Hellstern at microsoft.com <mailto:Alfred.Hellstern at microsoft.com> >:

Hello all,

The Visual Studio team is looking into the OPC review, but in the meantime they were wondering about the ZIP compression format:

“What is of more concern to me is no movement forward to support newer, better compression algorithms (i.e. based still on ZIP, which itself is limited to fairly light compression), and signature requirements to use only SHA1 which is no longer considered secure. Is the WG considering addressing these specifications while modernizing the OPC protocols? I appreciate that changing the container format is a daunting and perhaps irreconcilable task, but adding support for SHA256 or even dual-signing should be supported given that the signed XML specification that OPC uses has supported multiple signature algorithms for a very long time.”

What’s our take on moving forward from the current ZIP version we’re using? I suspect this also has to do with the version of ZIP that Windows itself uses in its Compressed Folders feature (and see this blog post https://blogs.msdn.microsoft.com/oldnewthing/20180515-00/?p=98755 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblogs.msdn.microsoft.com%2Foldnewthing%2F20180515-00%2F%3Fp%3D98755&data=02%7C01%7CAlfred.Hellstern%40microsoft.com%7C47c250fcd9c34a3ff95908d6827f1807%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636839879712056531&sdata=lU5OLp1tfml84tYlAaasgSDePDLJdBqYYpNk9wzod7Y%3D&reserved=0>   indicating that’s not going to -ever- change.

Alfred

Click here <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mailcontrol.com%2Fsr%2FMZbqvYs5QwJvpeaetUwhCQ%3D%3D&data=02%7C01%7CAlfred.Hellstern%40microsoft.com%7C47c250fcd9c34a3ff95908d6827f1807%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636839879712066540&sdata=T8bitOHcObttmrZ6i9uPw1fNEbuq0KPADz%2BYydK569c%3D&reserved=0>  to report this email as spam.

This message has been scanned for malware by Forcepoint.  <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.forcepoint.com%2F&data=02%7C01%7CAlfred.Hellstern%40microsoft.com%7C47c250fcd9c34a3ff95908d6827f1807%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636839879712066540&sdata=2yqQkL%2Bb3AVK1xTJUz7FQlgRLF5p3C4dyInjeW31VgY%3D&reserved=0> www.forcepoint.com

-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20190129/7e26084d/attachment-0001.html>