html5/webstorage Overview.html,1.184,1.185

Update of /sources/public/html5/webstorage
In directory hutz:/tmp/cvs-serv10315

Modified Files:
	Overview.html 
Log Message:
New topics: DOM APIs, and Security. (Note that by default, people are _not_ subscribed to new topics.) Also, some tweaks to the previous annotations. (whatwg r6836)

Index: Overview.html
===================================================================
RCS file: /sources/public/html5/webstorage/Overview.html,v
retrieving revision 1.184
retrieving revision 1.185
diff -u -d -r1.184 -r1.185
--- Overview.html	4 Oct 2011 17:01:23 -0000	1.184
+++ Overview.html	23 Nov 2011 20:02:07 -0000	1.185
@@ -214,7 +214,7 @@
    <p><a href="http://www.w3.org/"><img alt="W3C" height="48" src="http://www.w3.org/Icons/w3c_home" width="72"></a></p>
 
    <h1>Web Storage</h1>
-   <h2 class="no-num no-toc" id="editor-s-draft-4-october-2011">Editor's Draft 4 October 2011</h2>
+   <h2 class="no-num no-toc" id="editor-s-draft-23-november-2011">Editor's Draft 23 November 2011</h2>
    <dl><dt>Latest Published Version:</dt>
     <dd><a href="http://www.w3.org/TR/webstorage/">http://www.w3.org/TR/webstorage/</a></dd>
     <dt>Latest Editor's Draft:</dt>
@@ -319,7 +319,7 @@
   </dl><p>The W3C <a href="http://www.w3.org/2008/webapps/">Web Applications
   Working Group</a> is the W3C working group responsible for this
   specification's progress along the W3C Recommendation track.
-  This specification is the 4 October 2011 Editor's Draft.
+  This specification is the 23 November 2011 Editor's Draft.
   </p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5
   February 2004 W3C Patent Policy</a>. W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/42538/status" rel="disclosure">public list of
   any patent disclosures</a> made in connection with the deliverables
@@ -628,7 +628,7 @@
   determining the number of properties present, or as part of the
   execution of any of the methods or attributes defined on the
   <code><a href="#storage-0">Storage</a></code> interface, the user agent must first
-  <span>obtain the storage mutex</span>.<h4 id="security-localStorage"><span class="secno">4.3.1 </span>Security</h4><p>User agents must throw a <code>SecurityError</code> exception
+  <span>obtain the storage mutex</span>.</p><h4 id="security-localStorage"><span class="secno">4.3.1 </span>Security</h4><p>User agents must throw a <code>SecurityError</code> exception
   whenever any of the members of a <code><a href="#storage-0">Storage</a></code> object
   originally returned by the <code title="dom-localStorage"><a href="#dom-localstorage">localStorage</a></code> attribute are accessed
   by scripts whose <span>effective script origin</span> is not the
@@ -637,7 +637,7 @@
   the <code title="dom-localStorage"><a href="#dom-localstorage">localStorage</a></code> attribute was
   accessed.<p class="note">This means <code><a href="#storage-0">Storage</a></code> objects are neutered
   when the <code title="dom-document-domain">document.domain</code>
-  attribute is used.<h3 id="the-storage-event"><span class="secno">4.4 </span>The <code title="event-storage"><a href="#event-storage">storage</a></code> event</h3><p>The <dfn id="event-storage" title="event-storage"><code>storage</code></dfn> event
+  attribute is used.</p><h3 id="the-storage-event"><span class="secno">4.4 </span>The <code title="event-storage"><a href="#event-storage">storage</a></code> event</h3><p>The <dfn id="event-storage" title="event-storage"><code>storage</code></dfn> event
   is fired when a storage area changes, as described in the previous
   two sections (<a href="#sessionStorageEvent">for session
   storage</a>, <a href="#localStorageEvent">for local
@@ -827,7 +827,7 @@
   sensitive; it's quite possible for e-mails, calendar appointments,
   health records, or other confidential documents to be stored in this
   mechanism.<p>To this end, user agents should ensure that when deleting data,
-  it is promptly deleted from the underlying storage.<h2 id="security-storage"><span class="secno">7 </span>Security</h2><h3 id="dns-spoofing-attacks"><span class="secno">7.1 </span>DNS spoofing attacks</h3><p>Because of the potential for DNS spoofing attacks, one cannot
+  it is promptly deleted from the underlying storage.</p><h2 id="security-storage"><span class="secno">7 </span>Security</h2><h3 id="dns-spoofing-attacks"><span class="secno">7.1 </span>DNS spoofing attacks</h3><p>Because of the potential for DNS spoofing attacks, one cannot
   guarantee that a host claiming to be in a certain domain really is
   from that domain. To mitigate this, pages can use TLS. Pages using
   TLS can be sure that only the user, software working on behalf of
@@ -855,7 +855,7 @@
   user's wishlist; or a hostile site could set a user's session
   identifier to a known ID that the hostile site can then use to track
   the user's actions on the victim site.<p>Thus, strictly following the <span>origin</span> model described
-  in this specification is important for user security.<h2 class="no-num" id="references">References</h2><p>All references are normative unless marked "Non-normative".</p><dl><dt id="refsCOOKIES">[COOKIES]</dt>
+  in this specification is important for user security.</p><h2 class="no-num" id="references">References</h2><p>All references are normative unless marked "Non-normative".</p><dl><dt id="refsCOOKIES">[COOKIES]</dt>
       <dd><cite><a href="http://tools.ietf.org/html/rfc6265">HTTP State Management Mechanism</a></cite>, A. Barth. IETF.</dd>
 
    <dt id="refsDOMCORE">[DOMCORE]</dt>

Received on Wednesday, 23 November 2011 20:02:14 UTC