3.4.2 "DOM <code>Node</code> objects" browser DOM nodes often have state that isn't apparent in the DOM --- e.g., the contents of a <canvas>, or the state of form controls. Please clarify that this state is not restored and ONLY the listed attributes and children may be restored.
<br><br>3.4.2 "other objects" this is entirely ECMAscript specific, is it not? How can this work across language bindings? It might be a lot simpler for everyone to only specify storage for DOM types.<br><br><a href="http://3.4.6.1">
3.4.6.1</a> "The space limits on <span>public storage areas</span> should not affect
   the limits for non-public domains, however." The definition of "public" is troublesome, as you note below. With this policy the most reasonable thing for implementors is to be conservative about what domains are declared "public" ... allowing denial of service attacks against sites in deeper/obscure public domains but preventing sites from grabbing unlimited storage. Of course grabbing lots of domain names isn't unthinkable so UAs will probably need additional mechanisms to manage quota. Some more discussion of this problem would be helpful.
<br><br><a href="http://3.4.6.2">3.4.6.2</a> Is it obvious what "run to completion" means for a script? I think here you need to say that the intended semantics is that *as far as scripts can tell*, there is no concurrent script execution, and hence no concurrent access to storage objects, and any implementation technique that preserves this is allowed. If that's not the intended semantics, it should be! The behaviour currently described is one such technique but there could
be others (e.g., optimistic transactional script execution).<br><br>Two things that I didn't see that I think should be mentioned; apologies if they are:<br>-- From the security discussion, it's obvious that UAs are permitted to arbitrarily discard persistent storage data. This should be stated up-front. Exactly *when* is such discarding permitted, though?
<br>-- There should be some atomicity property that authors can rely on to safely update storage under potential failures (of the UA, or the hardware, or whatever). It's probably enough to require that setItem and removeItem are atomic with respect to failure. In other words, if the UA fails during a setItem or removeItem, then later the operation will be observed to either have succeeded normally or not happened at all (and of course the storage object will not be corrupted!).
<br><br>Rob<br>-- <br>["Therefore, my dear friends, as you have always obeyed–not only in my<br>presence, but now much more in my absence–continue to work out your<br>salvation with fear and trembling, for it is God who works in you to will
<br>and to act according to his good purpose." Philippians 2:12-13.]