I believe Thomas gave technical reasons, that I agree with, why it is
unnecessary to do this rework.
We are not using the transform chain where complexity and performance
issues occur, and the schema concerns as far as I can tell are a non-
issue as Thomas noted. What does " rely on XSD" as an issue mean, when
we do not require schema validation? Is it a problem to use schema to
express types (e.g. anyURI to mean put a URI as an attribute value etc)
XML Security is also an existing solution since 2002 and is profiled
down in this case. There are already XML implementations.
So apart from personal preference I do not see why a change is needed.
regards, Frederick
Frederick Hirsch
Nokia
On Apr 15, 2009, at 3:00 PM, ext Jonas Sicking wrote:
On Tue, Apr 14, 2009 at 4:38 AM, Marcos Caceres <[email protected]>
wrote:
Although I agree that it was probably a short-sightedness mistake on
our part to not have looked at JAR signing at the start of this
process, I think it is too late for you to ask us to dump over a year
worth of work on this spec - especially as we are about to go to Last
Call and have significant industry support (BONDI) for using XML
Signatures. Although I also agree that there are issues with
canonicalization, I find it hard to believe that JAR signatures are
not without their own problems. I think it would be more productive
to
help us address the issues that you mentioned, instead of asking us
to
dump everything and start again.
This is a really bad reason not to rework the widget signing spec. I
really hope that there are other more technical reasons that is
keeping us from reworking the spec. As an example the CORS spec had
been in the works for the better part of two years when we started
making some serious changes to it based technical input from reviews.
In the end we ended up adding and removing so many things that nothing
from the original spec was left in. And we were all better off because
of it.
Signing of archives is something that has been solved for a long time
at a significantly lower complexity than the current spec. So it
really shouldn't take that much effort to rework the spec by taking
input from existing solutions.
I'm not suggesting scrapping the spec and starting over. However do
take a look at even the bigger technical solutions in the spec and see
if they can be improved.
Given W3Cs philosophy of what is allowed to be standardized under W3Cs
roof, the fact that the spec reuses W3C specs carries very little
weight with me. For example the fact that it relies on XSD means that
it's a non-started for me.
I'm also not sure why we need to rely on canonicalizing XML files.
/ Jonas
