Re: [office-comment] ZIP specification for ODF 1.2

[rjelliffe@allette.com.au]

> Dear ODF TC,
>
> I am just curious at the following issue:
> Is zip a standard?

No, not all of it.

The functionality of ZIP has not been documented, QAed and voted for by an
organization with a balance of interests and reasonable committee
procedures.

However, ZIP obviously underlies several standards (like ODF) or
quasi-standards (like Java). Several of these have basic descriptions or
profiles of ZIP.

However, the DEFLATE algorithm which ZIP introduced is a standard (and
used by many other standards such as PNG and ZLIB): RFC 1951
http://tools.ietf.org/html/rfc1951

So large chunks of ZIP are in fact standardized, but not the whole thing,
and AFAIK the chunks are not specified enough to make a complete thing.

Standards are often created to resolve or to prevent some technical
dispute. In the case of ZIP, the basic technology has been around since
the late 1980s and there is no disagreement (that I know of) about what
ZIP is. (The standards use almost the simplest versions of ZIP possible,
to avoid any murky waters for IP.)

> If it is not, can one legally reference the zip-format within another
> ISO/OASIS/???-standard?

Every organization has different rules. (And "legally" is not the right
word, at least for voluntary IT standards.)

In the case of ISO/IEC JTC1, the general policy is in JTC1 Directives
Appendix N. There are a range of considerations. Very roughly:

 * Almost anything can be referenced informatively.

 * Obviously it is the normal and expected case that a standard only
normatively references other standards.

 * However, this is sometimes difficult, especially in the case of
standards transposed from external organizations (like OASIS).

 * The important case is that an "emerging" standard may want to
standardize some parts of the technology first (for logistical reasons,
for example.) Just what "emerging" is not clear to me--is it
pre-standardization, is it pre-stabilization?: but the intent is
obviously not to frustrate the progress of the standardization on a
technicality.

 * So JTC1 has various checks and balances to weed out normative
references to non-standardized specification that might cause trouble,
primarily by making sure all the cards are on the table. The documents
must be openly available (public, in English or French) and IP-suitable,
in particular.

 * The ultimate decision is the National Body ballot at SC level (though
JTC1 will vet.)

In the case of ODF, there was discussion at SC34 in 2007 on making a ZIP
standard. I wrote to PKWARE to sound them out but they did not reply. Last
year at an SC34 meeting a MS person said they would have better access,
but I don't think anything concrete came out of it either. PKWARE don't
care about their users in this regard, I would say: they compete on
higher-level functionality that would be excluded from a standard.

I gather that this discussion of a possible ZIP standard, plus the
standardization of DEFLATE, plus the long availability of the ZIP appnote,
plus the good IP status of ZIP, plus the maturity, neutrality and wide
deployement of ZIP, plus that ODF was an external specification and
'emerging', was enough that JTC1 felt comfortable not intervening at that
time on the ZIP reference. Ditto with ZIP in OOXML. (I would certainly
expect that an International Standard from an external source which had a
normative reference to a non-standard specification could not be moved to
"stabilized" status, however.)

Personally, I tend to think that IETF would be a better place for a simple
ZIP spec, because it is the home for deflate. It would be roughly ZIP 2
with deflate and no encryption, but requiring UTF-8 part names. ZIP is not
really an internet technology, but its technologies are very bit-ty
(rather than character-y like W3C, or structured-information-y like
OASIS.)

I think eventually we will see a ZIP standard, but it does not have any
urgency since there is no dispute to be resolved or avoided or mediated by
having a standard. And there is a strong desire, I think, not to add to
burden of standards-developers for bureaucratic box-ticking reasons. Most
standards have holes that a canon could shoot through, in some part,
especially in their first incarnations. Of course that causes problems,
but standards-making is a human activity.

Cheers
Rick Jelliffe