Re: quibbles about the spec

Thanks Jim for taking the time to review. Comments inline.

On 2013-06-06 21:28, Jim Barnett wrote:
> 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…”?

This is a bit messy. The async section was a central part of the 
pre-JSEP API constructor, but I think it's pretty much non-existent in 
the current version. We need to do some cleaning here.

> In 5.1.1 on the data channel we have:
> |ondatachannel| of type EventHandler,
> This event handler, of type |datachannel
> <>|,
> /MUST/ be supported by all objects implementing the |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?

It's purely an editorial thing to have somewhat isolated features in 
their own sections.

> 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?

Sounds reasonable to me.


Received on Monday, 10 June 2013 12:28:04 UTC