UTF-8 in ZIP
Dennis E. Hamilton
dennis.hamilton at acm.org
Wed Nov 3 18:47:05 CET 2010
+1 on this part, with no reservations. I think this is exactly the job for
finding a profile that serves those of us interested in having a common
substrate/carrier for packaging multi-component document representations.
That is all I meant, not that long ago, in speaking of a Zip/D (by analogy
with PDF/A as a profile of PDF).
(Well, I can conceive of not having 100% interoperability with some oddball
implementation for another purpose, or that has some bizarre file-system
characteristics that it expects to be reflected in the Zip directory names
for files, but such deviations are always conceivable.)
From: sc34wg1study-bounces at vse.cz [mailto:sc34wg1study-bounces at vse.cz] On
Behalf Of robert_weir at us.ibm.com
Sent: Wednesday, November 03, 2010 06:09
To: Alex Brown
Cc: sc34wg1study-bounces at vse.cz; sc34wg1study at vse.cz
Subject: RE: UTF-8 in ZIP
[ ... ]
My perception of the interests are:
1) Some want to ensure that document packages are and remain 100%
compatible with existing ZIP-based tools and libraries.
2) Some want there to be a formal standard for a royalty-free archive
format, suitable for use in document packages.
3) Some want to ensure that there is no fork of the existing ZIP
Application Note, e.g., an independent standard that might diverge in the
future and cause interoperability problems.
[ ... ]
So how can we satisfy all three interests? I think that one way has
already been discussed:
Create a profile standard of ZIP Application Note. It references the ZIP
Application Note via an RER.
Interest #1 is satisfied because the profile would only subset ZIP. It
would not introduce any new structures at the ZIP level, though it might
add requirements at the payload level.
Interest #2 is satisfied, because the RER would contain a patent statement
and PKWARE would be asked to review and approve this. So it would lead to
the desired greater clarity around IPR. They would also get a formal
standard in the form of the profile standard.
Interest #3 is satisfied because we would be profiling ZIP, not creating
an independent fork of the core ZIP Application Note.
If anyone else can suggest an alternative way of resolving these three
interests, then please speak up. I'm all ears.
sc34wg1study mailing list
sc34wg1study at vse.cz
More information about the sc34wg1study