OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [office] RE: Directories in Zip packages


Arrgh :-) Folks, this is going back and forth, while I really would like to see some work on XAdES :-)

My suggestion:

- discourage (but not forbid) the use of empty directories and empty files in ODF packages
- sign everything in the zip (including empty directories and empty files)
- change the 1.2 draft about document signatures and mention "sign every entry" instead of 
"sign every file"

This means there's no impact on unsigned ODF docs (because every implementation can still
use empty things, although it is discouraged)

There is impact on signed implementations signing/verifying signed docs, but those products
probably have to be updated anyway (to support correct prefixes, version attributes etc)


Bart


________________________________________
From: Dennis E. Hamilton [dennis.hamilton@acm.org]
Sent: Monday, September 27, 2010 7:30 PM
To: 'Svante Schubert'
Cc: ODF TC List
Subject: RE: [office] RE: Directories in Zip packages

Svante, a sub-document doesn't have to be an "actual" directory in any
literal sense.  This was clear in ODF 1.0/1.1 and I know of nothing that
requires us to change that.

The sub-document <manifest:file-entry> simply has to specify a "path" prefix
that some of the package files share and that are treated as a collection
with respect to the manifest:media-type.  Otherwise we would be in a world
of hurt with manifest:full-path="/".

We don't have nor require that "META-INF/" be declared as a sub-document or
have a directory entry in the package, nor do we do so for "Thumbnail/" and
so on.

When there is an ODF Package-significant use for declaring empty
directories, we should treat it as an extension case.  In the meantime, I
think we should give consumers a break here, especially around document
security issues.  A speculative future scenario is no help to a consumer who
stumbles on one of these now because of some inscrutable producer behavior.

 - Dennis

-----Original Message-----
From: Svante Schubert [mailto:Svante.Schubert@oracle.com]
Sent: Monday, September 27, 2010 09:20
To: office@lists.oasis-open.org
Subject: Re: [office] RE: Directories in Zip packages

On 27.09.2010 16:57, Bob Jolliffe wrote:

        ...

        So I would say that an odf producer should only produce entries in
the
        zipfile for non-zero-length streams (this would by default also
        excludes directories).  And that each of these shall be referenced
in
        a full document signature.

May I remind the TC, that from the perspective of the package (ODF 1.2 part
3 - which can be seen as the base layer of ODF 1.2) an entity called a
document is defined by a directory related with a media type (in the
manifest.xml).

In general I believe when a generic functionality does not hurt, it should
not be forbidden nor dropped as other yet unknown user scenarios might rely
on it.

Regards,
Svante


--


 <http://www.oracle.com/>
Svante Schubert | ODF Standardization
Phone: +49 40 23646 965
Oracle Office GBU

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

 <http://www.oracle.com/commitment>

Oracle is committed to developing practices and products that help protect
the environment







---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]