Re: [widgets] Rule for extracting file data from a file entry

On Wed, Jun 10, 2009 at 4:48 PM, Anne van Kesteren<annevk@opera.com> wrote:
> "The rule for extracting file data from a file entry is described in this section." This begs the question what a section is in this specification. It seems that the next paragraph defines this algorithm rather, not the whole section. Hopefully this becomes more clear when you restructure it to have useful sections.
>

I've added section numbers to all <h4>s. Hopefully that makes it more
clear that those are sections and not paragraphs, wdyt?

> "Exactly how to extract a file from a Zip archive is beyond the scope of this specification. Instead, implementers must follow the [ZIP] specification's instructions on how to extract a file from the Zip archive." I suggest to drop the first sentence as the next sentence makes it in scope (although the specification defers to another specification for the actual algorithm).
>

Editorial: Dropped the sentence.

> "It is optional for a user agent to extract all the files in a Zip archive at the same time. The user agent may extract specific files as they are needed for processing." I think this should be an informative note instead as you cannot test this assertion so it is irrelevant.
>

Editorial: Agreed, this is untestable. Changed to a note.

> "As a security precaution, implementations are discouraged from extracting file entries from un-trusted widgets directly onto the file system. Instead, implementations should consider a virtual file system or mapping to access files inside" Please do not use RFC 2119 terminology in non-normative text.
>

I have checked all sections marked as non-normative and made sure I
removed 2119 terminology.

> I also think it is bad form to put security precautions in a note.

I understand, but making the security precaution normative would also
result in a non-testable assertion. Do you have a better suggestion as
to what I should do here or should I leave it as is (that is, leave it
as a note)?

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

Received on Monday, 29 June 2009 14:12:37 UTC