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


On 27 September 2010 17:28, Dennis E. Hamilton <dennis.hamilton@acm.org> wrote:
> +1
>
> Yes, I think we should define the confirming-package Zip to not include
> 0-length stuff, whether thought to be directories or files (although I have
> a counter-example where a 0-length file if compressed has non-zero
> compressed size (2 bytes, actually).

yes I see the 2 byte compressed file data sections as well.

>
> I also agree that consumers *should* be permissive for the use case you
> describe.
>
> -----Original Message-----
> From: Bob Jolliffe [mailto:bobjolliffe@gmail.com]
> Sent: Monday, September 27, 2010 07:58
> To: robert_weir@us.ibm.com
> Cc: Hanssens Bart; dennis.hamilton@acm.org; David LeBlanc; Cornelis Frank;
> office@lists.oasis-open.org
> Subject: Re: [office] RE: Directories in Zip packages
>
> [ ... ]
>
> 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.
>
> An odf consumer, when validating a signature, shall verify that the
> signature references all non-zero-length entries in the package.  The
> presence of other zipentries in the package could be either ignored or
> treated as an error.  Following Postel, I am leaning towards the more
> permissive approach.  The benefit of simply ignoring being that it
> would allow naive general purpose zip tools to produce valid odf
> files, even though they would likely be violating the recommendation
> above regarding odf producers.  I think this is reasonable given the
> various toolchains people might construct which might involve an
> eventual packaging stage using pkzip or something similar.
>
> [ ... ]
>
>


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