[whatwg] Peer-to-peer communication, video conferencing, <device>, and related topics

[Harald Alvestrand]

Up front statement, orthogonal to the details of the specification:

I've discussed this interface somewhat with Ian before in private, and 
don't agree with his approach on several points - both technical and 
organizational.

I also don't believe that quick iteration and rapid prototyping is best 
served by putting this spec inside the HTML5 specification, and have 
therefore been working on an independent specification document. 
Unfortunately my skills at writing HTML-type specs are nowhere near 
Ian's, so it's taken much more time than desirable to get the proposal 
I'm writing up into a shape where I dare show it in public without 
feeling embarrassed (weakening my own argument somewhat). Still, I'm 
hoping to have it available in a matter of days.

I also don't believe that having all the discussions related to HTML5 on 
a single mailing list is an optimal approach, and will therefore be 
suggesting another mailing list for the public discussion of that 
specification. I haven't figured out which one yet.

Now on to details....

On 03/18/11 05:45, Ian Hickson wrote:
> When replying to this e-mail please only quote the parts to which you are
> responding, and adjust the subject line accordingly.
>
> This e-mail is a reply to about a year's worth of feedback collected on
> the topics of peer-to-peer communication, video conferencing, the<device>
> element, and related topics. This feedback was used to update the spec
> recently, greatly expanding on the placeholder that had previously
> sketched a proposal for how these features should work. (This e-mail does
> not include replies to most of the feedback received after the change to
> the spec. I'll be replying to the bulk of this more recent feedback in a
> separate e-mail soonish.)
>
> Here is a high-level overview of the changes; for specific rationales,
> please see the detailed responses to the e-mails below.
>
>   *<device>  has been replaced with a Geolocation-style API for requesting
>     user access to local media devices (such as cameras).
I have no issue with these.
>   * locally-generated streams can be paused and resumed.
I believe this property should be moved up to the "stream" level (which 
I prefer to call "StreamSource", because I think we also need an 
interface named "StreamSink").

I also believe that the recording interface should be removed from this 
part of the specification; there should be no requirement that all 
streams be recordable.

The streams should be regarded as a control surface, not as a data 
channel; in many cases, the question of "what is the format of the 
stream at this point" is literally unanswerable; it may be represented 
as hardware states, memory buffers, byte streams, or something 
completely different. Recording any of these requires much more 
specification than just "record here".
>   * the ConnectionPeer interface has been replaced with a PeerConnection
>     interface that interacts directly with ICE and its dependencies.
I disagree with a number of aspects of this interface. In particular, I 
believe the relationship between SDP and ICE is fundamentally misstated; 
it is possible, and often desirable, to use ICE without using SDP; there 
are other ways of encoding the information we need to pass.

In the RTCWEB IETF effort, the idea of mandating use of SDP is being 
pushed back on.

I also believe the configuration string format is too simplistic and 
contains errors; at the very least, we need a keyword:value format 
(JSON?) so that we can extend the configuration string without breaking 
existing scripts, and the STUN/TURN strings are incompletely defined 
(you can't specify that you're using TURN over TCP, for instance).
>   * PeerConnection has been streamlined (compared to ConnectionPeer), e.g.
>     there is no longer a feature for direct file transfer or for reliable
>     text messaging.
This is good. There was no backing specification for the corresponding 
wire formats.
>   * the wire format for the unreliable data channel has been specified.
I agree that before this functionality is implementable, we need a 
specification for its format. However, I don't believe the current 
specification is reasonable; it has complexities (such as masking) that 
don't correspond to a known threat model (given the permission-to-send 
model of ICE, the idea of cross-channel attacks using an ICE channel is 
irrelevant).
>   * the spec has been brought up to date with recent developments in other
>     Web specs such as File API and WebIDL.
Good.