UTF-8 in ZIP

[robert_weir at us.ibm.com]

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 
ISO standardization?

In any case I suppose I was thinking more of the following for advantages 
in SC34:

1) Thorough technical review of the specification, to remove any 
inadvertent ambiguities.

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 
standard.

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 
100% compatible.

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 
these alternatives.

-Rob