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


Given a ZIP entry of:  A/B

How do we know whether:

B is an empty directory in A

versus

B is a zero byte file in A?

I thought A/B was a file and A/B/ was a directory.

That said, there is a lot of code, including libraries,  out there that 
doesn't follow the above rule and relies on figuring out implicitly what 
directories need to be made, according to the paths encoded in non-zero 
byte files.  So I still think allowing zero-byte files or empty 
directories is a portability concern.

-Rob



"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 09/27/2010 
05:11:41 PM:

> RE: [office] RE: Directories in Zip packages
> 
> -1
> 
> Unless there is a proposal for how to accomplish the signing of
> "directories" via XML Digital Signature (and also directory entries for
> package files, which we don't sign either).
> 
> Please include a specific rule for knowing what is a directory entry in 
the
> Zip, because there is no help in APPNOTE 6.2.0 that I can find.
> 
>  - Dennis
> 
> -----Original Message-----
> From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
> Sent: Monday, September 27, 2010 10:42
> To: dennis.hamilton@acm.org; 'Svante Schubert'
> Cc: ODF TC List
> 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
> 
> 
> ---------------------------------------------------------------------
> 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 
> 
> 
> ---------------------------------------------------------------------
> 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]