[WIDGETS] Using Zip based on OOXML-OPC, was [WIDGETS] Zip Support (request for comments)

Ok, in response to Jon's comments, and in the interest of exploring
the OOXML-OPC path, here is some new text for discussion:

=Zip file=

For the purposes of this specification, A valid Zip file is a byte
stream or file that conforms to the production of a .Zip file as
defined by the the Zip File Format Specification [ZIP], but in
conformance with Section 9.2 (excluding section 9.2.6) and Annex C of
the [OOXML-OPC] Specification, and with the exclusion or support for
the following features. A Zip file that does not conform with the
aforementioned sections of [OOXML-OPC] or is in non-conforming with
any of the items listed below, is considered to be an invalid Zip
file. In the event that a widget user agent encounters an invalid Zip
file during the Procedures for Processing a Widget Resource (defined
elsewhere), the widget user agent must abort any processing and should
inform the end-user with an appropriate localized error dialog:

A Zip file must not be split into multiple files or span multiple
volumes as defined in [ZIP]. Zip files that are split into multiple
files or span multiple volumes are non-conforming. A widget user agent
must treat a Zip file that has been split into multiple files or span
multiple volumes as being an invalid Zip file.

A Zip file must be created using the Deflate compression method as
defined in [ZIP]. A Zip file compressed with any other compression
method is non-conforming. A widget user agent must treat a Zip file
created using other compression methods as being an invalid Zip file.
A widget user agent must support the Deflate decompression method
defined in [ZIP] to claim conformance to this specification.

A Zip file may be created using the Zip64 extensions as defined in
[Zip], but preferably only when a widget resource exceeds
4,294,967,296 bytes. A widget user agent must support Zip64 extensions
to claim conformance to this specification.

A Zip file must not be encrypted using any encryption method defined
in [ZIP]. Widget user agents must treat encrypted Zip files as being
an invalid Zip file. Widget user agents are not required to support
any decryption methods defined in [ZIP] to be conformant with this
specification.

A Zip file must not be digitally signed using any of the methods
defined in [Zip] (instead, a Zip file may be digitally signed using
the procedure for signing a widget resource defined in this
specification). Widget user agents must treat Zip files digitally
signed with methods other than the one defined in the Digital
Signature Section of the this specification as being an invalid Zip
file.

The names of files and directories within a Zip file must only be
encoded in US-ASCII (IBM Code Page 437) or UTF-8, but only if general
purpose bit 11 is set in accordance with Appendix D of the [ZIP]
specification (ie. set if UTF-8 or unset of US-ASCII). A widget user
agent must treat a Zip file that has files or directory names outside
the valid range of characters for file and directory names (defined
elsewhere) as being an invalid Zip file. A widget user agent must
treat Zip files with file or directory names in any encoding other
than US-ASCII or UTF-8 as as being an invalid Zip file.

Note: Please refer to Appendix D - Language Encoding (EFS) in the Zip
specification for the technical details of how to indicate that a zip
file contains UTF-8 file and directory names. Appendix D also
describes how to identify the use encodings other than UTF-8 via the
0x0008 Extra Field.

==Extensibility==

A widget resource can be created using proprietary extensions to the
[Zip] specification so long as the resulting widget resource can be
interoperably processed across widget user agents, and are still a
valid Zip file (as defined in the section above). Zip files that
cannot be processes by other widget user agents are non-conforming and
must be treated as an invalid Zip file.

Kind regards,
Marcos

-- 
Marcos Caceres
http://datadriven.com.au

Received on Sunday, 7 October 2007 08:46:45 UTC