- From: Marcos Caceres <marcosc@opera.com>
- Date: Fri, 17 Apr 2009 13:54:49 +0200
- To: Henri Sivonen <hsivonen@iki.fi>
- CC: Robin Berjon <robin@berjon.com>, Frederick Hirsch <frederick.hirsch@nokia.com>, ext Jonas Sicking <jonas@sicking.cc>, Thomas Roessler <tlr@w3.org>, public-webapps <public-webapps@w3.org>
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
Received on Friday, 17 April 2009 11:55:49 UTC