W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2013

Re: quibbles about the spec

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Mon, 10 Jun 2013 14:27:39 +0200
Message-ID: <51B5C63B.1070603@ericsson.com>
To: Jim Barnett <Jim.Barnett@genesyslab.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
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
> <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?

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.

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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:33 UTC