Hi Henri,
On 4/17/09 1:19 PM, Henri Sivonen wrote:
On Apr 17, 2009, at 13:24, Robin Berjon wrote:
Trying to separate the discussion from the change request: would you
be satisfied if requirements to perform C14N were removed and reliance
on XSD data types for definition purposes were replaced with something
less scary (though in this case this is a bit of a FUD argument Henri,
the referenced types aren't overwhelming)?
My preferred change would be adopting jar signing.
I don't think this is a realistic solution at this point, but we are
totally open to fixing what we currently have.
However, if that's
not feasible, my next preferred option would indeed be removing the
requirement to perform canonicalization (i.e. sign XML as binary with a
detached traditional binary signature block).
Agreed.
As for the data types, I'd be satisfied if the datatypes were defined in
such a way that attribute value parsing algorithms and conversion
methods that a browser engine has to contain anyway were reusable. This
should include well-defined behavior in the case of non-conforming input.
Agreed.
For example, for dates (which is a datatype that widgets add--not
something that comes from XML signatures), it makes more sense to reuse
an appropriate microsyntax definition from HTML5 than to delegate to
XSD.
Probably agree (need to read it, but makes sense... of course, you are
assuming that HTML5's definition is finished and without bugs - can you
guarantee this somehow? I.e., test cases that prove a 1 to 1 between
browser implementations and what is in HTML5?).
XSD not only makes leading and trailing whitespace conforming and
fails to define behavior in the case of non-conforming dates, XSD which
even allows leap seconds! (Is it a FUD argument that XSD dates deviate
from the value space that is typically used in Posix date conversions
between multi-unit tuples and epoch seconds?)
Yeah, Robin! :)
Kind regards,
Marcos
