UTF-8 in ZIP
robert_weir at us.ibm.com
robert_weir at us.ibm.com
Wed Nov 3 16:55:38 CET 2010
sc34wg1study-bounces at vse.cz wrote on 11/03/2010 10:10:39 AM:
> > What can we offer PKWARE?
> PKWARE has got world-wide acceptance of ZIP partly because
> PKWARE claimed that ZIP is in public domain. What we can offer is
> more formal status of this "contract" and no challenges to this
> world-wide acceptance.
It depends on what you think "public domain" means. Some have suggested
that this means that there is no copyright and that one can take the
Application Note and make derived works from it. But if we make an ISO
standard of this, surely ISO will claim copyright on that, and therefore
this hypothetical "public domain" aspect of it would be eliminated.
I happen to disagree with that interpretation of "public domain", but I'm
just pointing out that ISO standardization conflicts with that, since even
with publicly available specifications in ISO, they do not allow
modification and redistribution of their standards.
One could argue that "public domain" means something less, maybe that you
can freely distribute copies of the Application Note. But ISO
standardization would also eliminate that, since even with publicly
available specifications in ISO, they do not allow redistribution of the
standards. They would allow individuals to download a copy, via a click
through licence on their web site, at no charge. But the rights to
redistribute are reserved to ISO. You cannot even host a copy of a "free"
ISO standard on your organization's internal web server.
So, if (hypothetically) the success of ZIP were due to it having either
one of these "public domain" advantages, wouldn't both of them be lost via
In any case I suppose I was thinking more of the following for advantages
1) Thorough technical review of the specification, to remove any
2) Specification would be more "standards-like", perhaps easier to use.
3) Would make it easier for public sector to write requirements for ZIP
technology, since there increasingly is a preference for stating
requirements in terms of standards rather than proprietary specifications.
4) May have some marketing/publicity benefit to claim that their
technology is an ISO standard and their products conform to an ISO
5) May encourage additional standardization work to make ZIP integrate
with other cutting edge standards. This helps prolong the relevance of
ZIP into adjacent fields where it perhaps is not widely used yet.
So I think we could offer those advantages.
The disadvantage -- and I think this is a big one -- is there is nothing
that prevents SC34 from taking any ISO ZIP and diverging it from current
industry practice. Sure, that would be a dumb thing to do, but ISO
doesn't have any special anti-dumb pills that it gives to members. I think
we can all point to examples where even this SC took a standard and
diverged it from industry practice. ISO HTML, for example. In that case
the divergence was harmless because the ISO standard was ignored by the
market. But I've already heard on this list a number of ZIP-related
proposals made that would destroy compatibility with legacy ZIP tools and
libraries. So I suspect that the "control" aspect of the specification is
a critical point. I'd leave it to the rights owner to weigh the
advantages over the liabilities. Personally, I'd be more comforted if I
heard on the list more sensitivity from WG members to the need to remain
Personally, I don't think SC34 has any credible ability to "challenge" ZIP
technology with an alterative, since there are already a number of
standardized alternatives, e.g., GZIP in the IETF. There would probably
be very little NB support for creating "yet another archive format" given
More information about the sc34wg1study