Usage of ODF 1.2 package format

[GoogleCodeExporter]

The current draft of EPUB 3.0 references to the ODF 1.1 package format
http://idpf.org/epub/30/spec/epub30-ocf.html

The ODF TC approved on 2011-03-17 the ODF 1.2 Committee Specification 1.0.  
This is the highest level of approval we can give to the specification within 
an OASIS technical committee.  This is similar to an FCD in the ISO/IEC 
process.  After Committee Specification approval, the specification is next 
sent for approval by the general membership of OASIS. 

The package part is now a own document (part 3), you may find a reference here:
http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part3.html

It would be great if encryption and signature could align to ODF 1.2 so EPUB 
3.0 and ODF 1.2 application are interoperable, making software reusage easier!

Thanks,
Svante

Original issue reported on code.google.com by Svante.S...@gmail.com on 31 Mar 2011 at 1:59

[GoogleCodeExporter]

Original comment by markus.g...@gmail.com on 8 Apr 2011 at 7:12

• Changed state: Acknowledged

[GoogleCodeExporter]

Original comment by markus.g...@gmail.com on 8 Apr 2011 at 7:14

• Added labels: Type-ReviewComment

[GoogleCodeExporter]

Reassigning to Garth as James is away until the 25th. Note also Issue 124.

Original comment by markus.g...@gmail.com on 11 Apr 2011 at 8:19

[GoogleCodeExporter]

The two sentences that refer generically to ODF are:

The rules for ZIP physical containers build upon and are backward compatible 
with the ZIP technologies used by Open Document Format (ODF).

and

manifest.xml is an optional manifest of container contents, compatible with 
Open Document Format (ODF).

See issue #124 (http://code.google.com/p/epub-revision/issues/detail?id=124) 
for specifics of manifest.xml schema support.

It seems as though the two (above) generic (informative) references could be 
updated to the most-up-to-date 
(http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part3.html) 
specification for ODF without doing any harm.

Original comment by ga...@google.com on 12 Apr 2011 at 1:16

[GoogleCodeExporter]

To really determine whether our OCF3 is compatible with ODF 1.2 packaging, 
we have to look at "Open Document Format for Office Applications (OpenDocument) 
Version 1.2, Part 3: Packages", available at:

http://docs.oasis-open.org/office/v1.2/csprd03/OpenDocument-v1.2-csprd03-part3.h
tml

ODF 1.2 Packing uses Blowfish for encryption, and it is suboptimal.  I thus 
oppose to the use of ODF 1.2 packaging for EPUB3.

Original comment by eb2m...@gmail.com on 12 Apr 2011 at 1:49

[GoogleCodeExporter]

I do not see how this is a problem with the proposed "resolution" recommended 
above, as the two references to ODF are informative and generic.  OCF has its 
own packaging requirements that are more restrictive and normative.

If you disagree please propose concrete resolution.

Original comment by ga...@google.com on 12 Apr 2011 at 3:01

[GoogleCodeExporter]

There seems to be a misunderstanding regarding the usage of BlowFish.
ODF 1.2 allows different kind or encryption algorithms.

http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part3.html#at
tribute-manifest_algorithm-name

>  The defined values for the manifest:algorithm-name attribute are:
> 
>  •An IRI listed in §5.2 of [xmlenc-core]: The algorithm and mode specified 
in §5.2 of [xmlenc-core] for this IRI. 
> 
>     •Blowfish CFB: The Blowfish algorithm in 8-bit CFB mode. See 
[Schneier]. 
Blowfish is called "legacy algorithm" on most places where listed in the
ODF 1.2 specification.

It was intended that the ODF 1.2 specification recommend AES, uncertain why 
this is not the case (probably the editor thought referencing §5.2 of
[xmlenc-core] would be good enough, as we had lengthy discussions about
something like a "mandatory", or "default" algorithm)

We have already implemented AES-256 as the default encryption algorithm
for ODF 1.2 documents in the upcoming release of OpenOffice.org:

http://openoffice.org/projects/www/lists/allfeatures/archive/2011-03/message/2

Regards,
Svante

Original comment by Svante.S...@gmail.com on 12 Apr 2011 at 1:40

[GoogleCodeExporter]

The best way to solve this issue from a standard stand-point would be to 
normative reference and use ODF 1.2 and if OCF has its own packaging 
requirements that are more restrictive and normative, exceed the existing 
requirements of ODF 1.2, making them more restrictive and normative for OCF.

BTW: The manifest.xml as single point of information about the content of the 
package has it sense, e.g. for relating mimetypes with streams.

If you have any questions, I am happy to assist and we might as well have a 
call this week for a quick information exchange.

Original comment by Svante.S...@gmail.com on 13 Apr 2011 at 7:41

[GoogleCodeExporter]

Hmmm... to my read, the two references to "naked" ODF are informative 
(introduction and overview) and they could be to either 1.1 or 1.2 -- since 1.2 
is the newest, that seems fine.  Or for that, matter we could just point at the 
"oasis-open.org" site top level.  Our normative packaging 
requirements/restrictions are contained within our specification.

To my read, the only normative reference to ODF is in reference to the 
schema(s) allowed in manifest.xml (issue 124 
[http://code.google.com/p/epub-revision/issues/detail?id=124]) to which I 
propose a "1.1 or 1.2" solution, as we really don't care about manifest.xml for 
our uses.

Original comment by ga...@google.com on 13 Apr 2011 at 3:07

[GoogleCodeExporter]

There is currently a problem with accessing the latest draft - 
http://idpf.org/epub/30/spec/epub30-ocf.html
I wanted to get the idea of the different requirements you have on Signature 
and Encryption, previous it seems that both specs are based on the same 
references.

When using a different package than ODF 1.2 - just making a informative 
reference - EPUB 3 wlll fork the package, making it impossible for ODF 
application to easily open the EPUB 3 package and for EPUB 3 applications to 
reuse opensourced ODF libraries such as ODFDOM (see 
http://odftoolkit.org/projects/odfdom/pages/Layers), where the package layer is 
planned to bee split off into an own deliverable to be stand-alone usable by 
EPUB. 

Not to mention using the existing validation functionality for ODF packages, 
see http://odftoolkit.org/projects/conformancetools/pages/Home

If there are additional requirments to the ODF Package format, you should sent 
them to the ODF TC as a comment, see 
http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=office

Although Murata San believes that it is already too late to change the EPUB3 
specification draft, I really hope we are able to share software for the 
package in the future.

If there are any questions left, please contact me directly under 
Svante.Schubert @ oracle.com or during the next three weeks of my absence my 
colleague Michael Brauer, one of the ODF TC Chair.

Thanks,
Svante 

Original comment by Svante.S...@gmail.com on 14 Apr 2011 at 6:02

[GoogleCodeExporter]

Later this week, the following will go out as the "Chairs recommended 
resolution" to the working group.

OCF is informed by, but not claiming compatibility with, ODF.  To that end, the 
following changes to the current draft are recommended.

In OCF section 1.1, change "The rules for ZIP physical containers build upon, 
and are backward compatible with, the ZIP technologies used by [ODF]." to "The 
rules for ZIP physical containers build upon the ZIP technologies used by 
[ODF]."

In OCF section 2.2, change:

"manifest.xml [optional]

A manifest of container contents, compatible with Open Document Format (ODF)."

to:

"manifest.xml [allowed]

A manifest of container contents as allowed by Open Document Format [ODF]."

The above two references to ODF are informative and will be generic pointing to 
"http://www.oasis-open.org/standards".

In OCF section 2.5.3, remove "If present, the content of this file must be as 
defined in the ODF 1.1 manifest schema."

The working group may consider harmonization with ODF 1.2 in a future version.

Original comment by ga...@google.com on 19 Apr 2011 at 11:32

[GoogleCodeExporter]

In other words you recommend that signature and encryption should be specified 
different to ODF 1.2 although both use the same underlying technologies.
Making the package of OCF and ODF incompatible without technical reason?

Sorry, this hard to understand..

Original comment by Svante.S...@gmail.com on 21 Apr 2011 at 7:01

[GoogleCodeExporter]

Ideally, OOXML, ODF, EPUB, W3C Widget Packaging, and other should be unified
as far as packaging is concerned.  Unfortunately, all of them are halfly 
cooked, 
and already have too many differences.  Unification is not possible without 
causing serious problems to the schedules of these technologies.

ODF 1.2 is not at all perfect.  For example, unlike ocf-signatures-30.rnc and 
ocf-encryption-30.rnc in OCF3, ODF 1.2 packaging does not use RELAX NG schemas 
for XML Security (W3C Note).  Moreover, as you know, many people are unhappy 
with the way encryption is specified in ODF 1.0 and 1.1 (I don't know ODF 1.2 
well, though.)  OPC of OOXML has its own drawbacks.  For example, it does not 
even provide encryption.

Eventually, we might want to prepare some universal packaging format, possibly 
on top of 7-zip rather than zip.  To do so, we have to begin with thorough 
comparison of the packaging formats rather than a last-minute request to adopt 
ODF 1.2 packaging in EPUB3.

Original comment by eb2m...@gmail.com on 25 Apr 2011 at 6:31

[GoogleCodeExporter]

BTW, if I am not mistaken, ODF 1.2 Part3 Packages specifies nothing 
about permissible file names.  It does not even say which encoding 
is used for representing file names within a ZIP package.

Original comment by eb2m...@gmail.com on 25 Apr 2011 at 7:05

[GoogleCodeExporter]

Spec prose revisions have been incorporated in r2845

Original comment by mgarrish on 28 Apr 2011 at 4:21

• Changed state: Done