Re: Call for Consensus: ICE Transport Extensions for WebRTC


I don't understand (yet) where this is going. With this extension, one
can create an RTCIceTransport instance... which is standalone and not
associated to an RTCPeerConnection. So, there is nothing one can do with
it since the extension doesn't specify any kind of interaction between
itself and RTCPeerConnection.

Regarding the spec itself, a few questions and notes:

* The methods reference `state` but it's not an attribute or references
an internal slot.
* What happens if .gather() is being called again, possibly even after
.start() has been called?
* The .start() method:
  - What happens if .gather() hasn't been called, yet?
  - It refers to a `gatherer` argument in step 6 which doesn't exist (I
assume this is from the ORTC spec).
  - Why does `RTCIceRole` default to `controlled`?
* Missing definition of `RTCIceCandidateComplete` in
* How is an `RTCIceCandidate` instance being created before passing it
as an argument to .addRemoteCandidate(...)? In ORTC it's defined as a
dictionary but in WebRTC it's not. And I'm not aware of ways to create
an instance without `RTCIceCandidateInit` which requires SDP.
* 5.1 Impact on same origin policy: Shouldn't that mention that mode 2
will be used by default in case no consent (in whatever form) has been
provided? Also, not really sure why it refers to a "QUIC API" here.
* 5.2 Impact on local network: I'm unaware ICE encrypts anything. And it
also mentions using congestion control (also refers to QUIC for some
reason). Pretty sure that doesn't apply to ICE.
* 5.3 Confidentiality of Communications: Seems to be moot for an ICE
* There should be an example
(*). :)


On 17.04.2018 19:45, Bernard Aboba wrote:
> This is a call for consensus on the Editor's Draft "ICE Transport Extensions for WebRTC", which is being considered for acceptance as a WG document. 
> The document is available for inspection here: 
> Abstract
> This document defines a set of ECMAScript APIs in WebIDL to allow construction of an RTCIceTransport interface in situations where such an interface would not be created in the WebRTC 1.0 API (such as when data is exchanged using QUIC). This specification is being developed in conjunction with protocol specifications developed by the IETF ICE Working Group.
> Please respond to this email with your review (and opinions on whether it is ready for acceptance as a WG document) by May 4, 2018. 

Received on Tuesday, 17 April 2018 19:02:20 UTC