Re: Reminder: RfC: LCWD of Digital Signatures for Widgets; deadline 6 May 2010

Hi Frederick,

On 29/04/10 10:52 PM, Frederick Hirsch wrote:
> Marcos
>
> Given the massive number of changes, it would help if you could please
> summarize:
>
> 1. which original normative statement no longer are applicable (ie
> despite rewording, which no longer need be met)

In my proposal, I removed the following 2 normative statements:

1. "The URI attribute of every ds:Reference to a file entry MUST be a 
URL-encoded [URI] zip relative path that identifies a file inside the 
widget package."

2. "Within a widget package these signature files MUST be ordered based 
on the numeric portion of the signature file name."

For 1., I explained the rationale in point 2 of my previous email 
(zip-relative paths are IRI safe, hence no URL encoding is needed).

For 2., this puts an optimization requirement on the signer that is 
unnecessary (and might be beyond the control of the signer, as might be 
the case if I would manually be creating the zip file). The validator 
uses the "Locating and Processing Digital Signatures for the Widget" 
rule [1] in order to find signatures. That rule assumes that the 
signatures will be in a random order within the zip archive. Removing 2 
has no impact on current implementations (they are still totally valid 
and better than the average implementation as they are more optimized).

[1] http://www.w3.org/TR/widgets-digsig/#locating-signatures

Every other requirements still apply as originally intended.

> 2. which new normative statements you have added

I have not added any new normative statements.

I know it looks like I have made a lot of changes, but I have only moved 
stuff around and made it crystal clear to which product a  conformance 
requirement applies. This gives the illusion that a lot of changes have 
been made, but if you inspect the document closely you will see nothing 
much has actually changed (aside from the 2 things I removed above). I 
also removed unnecessary uses of RFC2119 keywords when appropriate 
without harming the original intent of any requirement. This is on 
purpose, of course: I don't want to slow down this work - only seek to 
improve its testability and its ability to be implemented.

Having said that, I hold that the changes are absolutely required to 
make this specification testable. I would like to point out that, as of 
last year, Dominique Hazaël-Massieux and the mobile test suite WG had 
foind the same problems with the spec. As a result, Dominique had also 
begun to make an alternative testable version of the specification [2] 
(because the specification was not originally edited with testability as 
one of its primary objectives - as original editor, I take 
responsibility for that due to my inexperience with specification 
engineering and QA). Eventually, when we actually start building the 
test suite, the issues I have addressed would have become a problem if 
we re-enter CR and would have forced us back to LC (as happened with 
P&C). I'm trying to avoid us having to return to LC in the future.

Having the clarifications I have made in my proposal give us a clean way 
to write tests for the specification increasing the likelihood of 
interoperability. This is now evident in [3] (test suite harness): my 
proposal now neatly shows what conformance requirements apply to what 
product. Making a test suite now is going to be much much much easier. 
[3] also now allows us to analyze the conformance criteria using the 
method described in "A Method for Writing Testable Conformance 
Requirements"[4].

I hope that all makes sense now and puts everyone's mind at ease wrt the 
changes I've made. Again, my proposal is just that, a proposal: I leave 
it to WG to reach consensus as to whether it should be adopted.

Kind regards,
Marcos

[2] http://www.w3.org/TR/widgets-digsig/Overview_TSE.html
[3] http://dev.w3.org/2006/waf/widgets-digsig/test-suite/
[4] http://www.w3.org/TR/test-methodology/

-- 
Marcos Caceres
Opera Software

Received on Friday, 30 April 2010 00:39:06 UTC