RE: quibbles about the spec

On further investigation, I withdraw my comment about  the remote side needing to be able to reject a datachannel.  As I now understand it from draft-ietf-rtcweb-data-channel,  the SCTP association is set up via the same offer/answer exchange that sets up the voice and video streams.  So a participant who doesn't  want a data channel can either not include the SCTP association in the offer it sends (if it is the offerer), or refuse it in the answer it returns.   So in this sense, the data channel is parallel to voice and video (which was my concern).  Once the SCTP association is set up, the receiving side can't choose to accept or reject individual data channels over that association (though it can close  them as soon as they are created).  That's fine.


-          Jim

From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
Sent: Thursday, June 06, 2013 3:29 PM
To: public-webrtc@w3.org
Subject: 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