- From: Marcos Caceres <marcosc@opera.com>
- Date: Fri, 30 Apr 2010 16:06:24 +0200
- To: Frederick Hirsch <frederick.hirsch@nokia.com>
- Cc: public-webapps WG <public-webapps@w3.org>
Hi Frederick, On Fri, Apr 30, 2010 at 2:37 PM, Frederick Hirsch <frederick.hirsch@nokia.com> wrote: > Marcos > > Thanks for taking the time to propose a revision to Widget Signature based > on your experience working on the test cases. This looks like a very good > improvement in readability and clarity of conformance requirements. > > From a technical point of view it looks to be fundamentally the same to me, > with a couple of changes noted here, though I may have missed something in > the large number of changes. Here are a few questions: > > 1. You removed requirement that signature be at root of widget package? This > seems an important requirement here for knowing which signatures are valid > (even if in packaging and config) I removed the requirement because by definition signature files are at the root: "A signature file is a file entry.... Signature files are located at the root of the widget package." But for the sake of clarity, I've added the requirement back in: [[A signer MUST place any generated signature file at the root of the widget package.]] > 2. The following signature validation rule in section 6 seems incorrect > since it does not account for author signatures: > > "A validator MUST ignore any file entry whose file name does not conform to > the naming convention for a distributor signature." > > Change to: > > "A validator MUST ignore any file entry whose file name does not conform to > the naming convention for an author or distributor signature." Fixed. > 3. The abstract was revised to generalize beyond widgets, which I don't > understand given that the entire specification is widget specific. What did > you have in mind. > >> allow a packaged Web application such as widgets I was thinking it could be used as a general thing for singing zip files, but you are right: the spec expects conforming widget packages to work. I've reverted that back to its original. > 4. Typo section 8, in note: Signign Fixed. > Regarding process, some of the changes and deletions remove material that > was added through decision of the WG earlier - although to me it appears to > be an improvement. Thanks. Fresh eyes and experience brought a new perspective. > So we need WG to agree to accept changes. Given that > the conformance targets have been redefined, that normative language has > been removed or changed, is another full Last Call (3 weeks) be required? > Maybe, but I'm not sure since apart from the questions above it looks like > the same net effect on implementations. I'll leave that up to the chair/team. I've tried my absolute best to not change the behavior of implementations. As Opera has already stated publicly, we are implementing this specification. It was Opera's internal effort to implement and create a suitable test-suite that prompted me to do this editorial clean-up (though I have been known to do strange things just for fun:)). Thank you again for your time reviewing the proposal. Kind regards, Marcos -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
Received on Friday, 30 April 2010 14:07:12 UTC