On Wed, Jun 10, 2009 at 4:48 PM, Anne van Kesteren<ann...@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
