quibbles about the spec

Adam,
  Here are a few nits from the latest editor's draft.

In section 4.3.1, we have:

*  Return connection, but continue these steps asynchronously.

*  Await a stable state. The synchronous section consists of the remaining steps of this algorithm.
>> Should the second bullet item say "The asynchronous section..."?

In 5.1.1 on the data channel we have:
ondatachannel of type EventHandler,
This event handler, of type datachannel<http://dev.w3.org/2011/webrtc/editor/webrtc.html#event-datachannel>, MUST be supported by all objects implementing the RTCPeerConnection<http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCPeerConnection> interface.

>> If anyone who implements PeerConnection must support the data channel, why is it a partial interface?  Why not just make it part of PeerConnection?

On the datachannel API, I know this has been discussed on the list, but there doesn't seem to be any way for the remote side to reject a data channel.  When you receive an offer, you can reject either audio or video (or both) by constraining/tweaking the answer.   Shouldn't there be a way to do this for data channels, too?  Is the idea that the receiving side could extract the DataChannel from the DataChannelEvent and close it immediately?  Doesn't that leave  a window in which a malicious peer could send a lot of data?

In 7.6 for RTCRTPStreamStats, given stats for a local object, remoteID can get the stats for the corresponding remote object.  Given the prose, it looks like it works the other way around as well:  if you have the stats for the remote side, you can use the remoteID attribute to get the stats for the corresponding object on your side.  (And if that's not the case, it ought to be the case.)  But it sounds odd to use 'remoteID' to access stats about your own side.  Would 'peerID' be a better name?


-          Jim