An outline proposal

Dennis E. Hamilton dennis.hamilton at
Fri Oct 15 04:28:48 CEST 2010

Personally, I think standardizing a fully-specified, independently usable
*subset* of Zip would be fine, with the proviso that it really be a subset
and that packages created with it would be fully acceptable as Zip packages.

To try for a full Zip and embrace the incredible variability of Zip, even to
the degree it is specified in APPNOTE 6.2.0 strikes me as madness.

Of course, IS 26300 profiles APPNOTE 6.2.0 now, and ODF 1.2 could do
something similar, such that we would be indifferent to any full-Zip
standardization at the ISO level so long as there was enough compatibility.
Future redrafting of profiling in order to appeal to an IS for which there
is actually no breaking change required in terms of how much of Zip is
relied upon by the referencing specifications is the easy case.  Those of us
who have such profiles can sit on the sidelines and make sure you SC34 WG1
doesn't break anything and we can go home happy.

More troublesome would be any composite-document structure grafted onto
packages as part of integrating with Zip but that don't have any impact on
Zip itself.  It is any effort in this area that would arouse the attention
of the ODF TC and, I presume, ECMA, SC34 WG4, and others.  The original NWI
proposal had such considerations in its scope with regard to inter-component
references within the package and potentially package-outbound and -inbound
as well.  If that is determined to be out-of-scope, we can also go home

 - Dennis

-----Original Message-----
From: sc34wg1study-bounces at [mailto:sc34wg1study-bounces at] On
Behalf Of Alex Brown
Sent: Thursday, October 14, 2010 02:05
To: Dave Pawson; ISO Zip
Subject: RE: An outline proposal

Dear all,

> Come on Alex, speak up.

Well it's a good question: are we proposing to standardize something which
just meets the immediate needs of format designers, or Zip-the-technology as
a general purpose archiving technology? Or are we (as Rob suggests)
effectively going to propose doing both by standardizing different levels of

The original proposal that failed its ballot very much focussed on a
"minimal" Zip that would work as a drop-in replacement for the file formats
in which SC 34 is most interested: 26300, 29500, EPUB and W3C Widgets. Part
of the thinking behind that was that we wanted to avoid accusations of doing
a "land grab" or of trying to appropriate PKWare's technology. However,
there was some worry in the ballot responses that by standardizing something
that was not Zip, we would be risking incompatibility. 

I would observe that the immediate problem faced by SC 34 is the question of
how to reference a non-standard technology (the subset of Zip used by e.g.
OOXML) in a way which is in accord with the JTC 1 referencing rules. We are
hearing from our liaison in W3C and our contacts in IDPF that a standard
version of Zip would be a useful thing for them too. So it seems to me the
need for at least a minimal Zip is established -- that is after all why this
study period is happening rather than the whole idea having been abandoned.

What is less certain is whether there's a requirement for standardizing
Zip-in-its-entirety. Participants in this group need to speak up based on
what they are hearing from the communities they represent. Or perhaps
another useful way to pose the question (this being a consensus-based
process) is: are there OBJECTIONS to such an effort? Or maybe a longer-term
compromise approach might be standardize a base-level Zip now, without
precluding the possibility that it might be extended to become a more
fully-featured Zip at a later date ...

- Alex.

This email has been scanned by the MessageLabs Email Security System.
For more information please visit 
sc34wg1study mailing list
sc34wg1study at

More information about the sc34wg1study mailing list