IndexedDB: negative zero as keys/values

There appears to be a minor edge case in the IndexedDB draft (
http://www.w3.org/TR/IndexedDB) - and inconsistencies between
implementations - for the ECMAScript "negative zero" number value. While the
other numeric edge cases - NaN and +/-Infinity - are called out explicitly
in the draft when discussing keys, negative zero is not. The intended
handling of -0 in values could, in theory, be covered by the HTML5
structured clone algorithm (
http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data),
but it also has no explicit mention of -0.

In Chrome 14, -0 and 0 are treated as the same key, and -0 values are read
back as 0. In Firefox 6, -0 is preserved as a value, but 0 and -0 are
treated as the same key. (I have not tested IE10)

e.g.
       store.put(-0, 'key for -0');
       store.put('value for key -0', -0);
       store.put('value for key 0', 0);

       store.get('key for -0').onsuccess = function (e) {
         assertEqual(-0, e.target.result, '-0 as a value'); };

       store.get(-0).onsuccess = function (e) {
         assertEqual('value for key -0', e.target.result, '-0 as a key'); };

.... for some suitably -0-aware assertEqual comparison - e.g.
http://wiki.ecmascript.org/doku.php?id=harmony:egal

This will "fail" in both cases in Chrome 14, and "fail" in the second case
only in Firefox 6.

In other words, in at least these two current implementations, -0 is treated
as the same key as 0. However, the two current implementations disagree
about storing/retrieving -0 values.

Should the draft codify the handling of -0 in keys? And is the handling of
-0 in values properly deferred to the structured clone algorithm?

-- Josh