fixes from Stefan's email

webrtc.html

@@ -293,29 +293,30 @@ <h4>Offer/Answer Options</h4>
 
         <dl class="idl" title=
         "dictionary RTCOfferOptions : RTCOfferAnswerOptions">
-          <dt>boolean offerToReceiveVideo</dt>
+
+          <dt>long offerToReceiveVideo</dt>
 
 
           <dd>
             <p>In some cases, an <code>RTCPeerConnection</code> may wish to
             receive video but not send any video. The
             <code>RTCPeerConnection</code> needs to know if it should signal to
             the remote side whether it wishes to receive video or not. This
-            option allows an application to indicate its preferences for
-            receiving video when creating an offer.</p>
+            option allows an application to indicate its preferences for the
+            number of video streams to receive when creating an offer.</p>
           </dd>
 
 
-          <dt>boolean offerToReceiveAudio</dt>
+          <dt>long offerToReceiveAudio</dt>
 
 
           <dd>
             <p>In some cases, an <code>RTCPeerConnection</code> may wish to
             receive audio but not send any audio. The
             <code>RTCPeerConnection</code> needs to know if it should signal to
             the remote side whether it wishes to receive audio. This option
-            allows an application to indicate its preferences for receiving
-            audio when creating an offer.</p>
+            allows an application to indicate its preferences for the number of
+            audio streams to receive when creating an offer.</p>
           </dd>
 
 
@@ -1206,7 +1207,9 @@ <h3>Interface Definition</h3>
             task to invoke <var>failureCallback</var> with a
             <code>DOMError</code> object whose <code>name</code> attribute has
             the value <code>IncompatibleConstraintsError</code>. Media must not
-            be transmitted to the other side in this case. TODO - Open Issue:
+            be transmitted to the other side in this case. </p>
+
+            <p class="note"> Open Issue:
             Waiting for Martin to see if the above should send black instead of
             doing what is above.</p>
 
@@ -1487,7 +1490,7 @@ <h3>Interface Definition</h3>
           <dd>
             <p>If a <code><a>MediaStream</a></code> object, with an
             <code><a href="getusermedia.html#dom-mediastream-id">id</a></code>
-            equal to <var>trackId</var>, exists in this
+            equal to <var>streamId</var>, exists in this
             <code><a>RTCPeerConnection</a></code> object’s stream sets
             (<a href="#local-streams-set">local streams set</a> or <a href=
             "#remote-streams-set">remote streams set</a>), then the <dfn id=
@@ -3282,8 +3285,7 @@ <h3>RTCDataChannel</h3>
           established.</p>
         </dd>
       </dl>
-      <!-- TODO these three closes are really weird - what is missing
-        earlier -->
+
     </section>
 
 
@@ -4065,7 +4067,7 @@ <h3>Identity Provider Interaction</h3>
       the IdP's specific requirements. Thus, a single browser can support any
       number of identity protocols, including being forward compatible with
       IdPs which did not exist at the time the browser was written. The generic
-      protocol details are described in [RTCWEB-SECURITY-ARCH]. This document
+      protocol details are described in [[!RTCWEB-SECURITY-ARCH]]. This document
       specifies the procedures required to instantiate the IdP proxy, request
       identity assertions, and consume the results.</p>
 
@@ -4079,8 +4081,7 @@ <h4 id="sec.identity-proxy-communications">Peer-Connection/IdP
         an isolated interpreted context [TODO: What's the technical term?],
         such as an invisible IFRAME. The initial contents of the context are
         loaded from a URI derived from the IdP's domain name.
-        [[!RTCWEB-SECURITY-ARCH; Section XXX]]. [TODO: update
-        https://raw2.github.com/tobie/specref/master/biblio.json]</p>
+        [[!RTCWEB-SECURITY-ARCH]]. </p>
 
 
         <p>For purposes of generating assertions, the IdP shall be chosen as
@@ -4158,6 +4159,7 @@ <h4 id="sec.create-identity-proxy">Instantiating an IdP Proxy</h4>
         remote side of the type of stream (ordinary, peerIdentity, noaccess) it
         is associated with. Implementations MUST have an user interface that
         indicates the different cases and identity for these.</p>
+
       </section>
     </section>
 
@@ -4172,20 +4174,20 @@ <h3 id="sec.identity-proxy-assertion-request">Requesting Assertions</h3>
 
       <ol>
         <li>The <code>RTCPeerConnection</code> instantiates an IdP context as
-        described in <a href="#sec.create-identity-proxy"></a>.
+        described in the previos section.
         </li>
 
 
         <li>The IdP serves up the IdP JavaScript code to the IdP context.</li>
 
 
         <li>Once the IdP is loaded and ready to receive messages it sends a
-        "READY" message [RTCWEB-SECURITY-ARCH; Section 5.6.5.2]. Note that this
+        "READY" message [RTCWEB-SECURITY-ARCH]. Note that this
         does not imply that the user is logged in, merely that enough IdP state
         is booted up to be ready to handle PostMessage calls.</li>
 
 
-        <li>The IdP sends a "SIGN" message (Section 5.6.5.2.2) to the IdP proxy
+        <li>The IdP sends a "SIGN" message to the IdP proxy
         context. This message includes the material the
         <code>RTCPeerConnection</code> desires to be bound to the user's
         identity.</li>
@@ -4203,7 +4205,7 @@ <h3 id="sec.identity-proxy-assertion-request">Requesting Assertions</h3>
 
 
         <li>Once the assertion is generated, the IdP proxy sends a response
-        (Section 5.6.5.2.2) containing the assertion to the
+        containing the assertion to the
         <code>RTCPeerConnection</code> over the message channel.</li>
 
 
@@ -4232,12 +4234,12 @@ <h3 id="sec.identity-verify-assertion">Verifying Assertions</h3>
 
 
         <li>Once the IdP is loaded and ready to receive messages it sends a
-        "READY" message [RTCWEB-SECURITY-ARCH; Section 5.6.5.2]. Note that this
+        "READY" message [RTCWEB-SECURITY-ARCH]. Note that this
         does not imply that the user is logged in, merely that enough IdP state
         is booted up to be ready to handle <code>PostMessage</code> calls.</li>
 
 
-        <li>The IdP sends a "VERIFY" message (Section 5.6.5.2.2) to the IdP
+        <li>The IdP sends a "VERIFY" message to the IdP
         proxy context. This message includes assertion from the offer/answer
         which is to be verified.</li>
 
@@ -4248,7 +4250,7 @@ <h3 id="sec.identity-verify-assertion">Verifying Assertions</h3>
 
 
         <li>Once the assertion is verified the IdP proxy sends a response
-        containing the verified assertion results (Section 5.6.5.2.3) to the
+        containing the verified assertion results to the
         <code>RTCPeerConnection</code> over the message channel.</li>
 
 
@@ -4271,7 +4273,7 @@ <h3 id="sec.identity-verify-assertion">Verifying Assertions</h3>
         and the identity returned by the IdP and must be displayed via some
         mechanism which cannot be spoofed by content. [[OPEN ISSUE: The
         identity information should also be available in the inspector
-        interface defined in [RTCWEB-SECURITY-ARCH; Section 5.5].</li>
+        interface defined in [RTCWEB-SECURITY-ARCH].</li>
       </ol>
     </section>
 
@@ -5455,6 +5457,8 @@ <h3>Changes since August 30, 2013</h3>
 
       <li> Changed the DTMF timing values. </li>
 
+      <li> Allow offerToReceiveAudio/video indicate number of streams to offer. </li>
+
       <li>ACTION-98: Added text about clamping of maxRetransmitTime and
       maxRetransmits.</li>