Subject: Re: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-overview-18: (with COMMENT)

From: Sean Turner <[email-masked]>
Date: Tue, 16 May 2017 12:36:37 -0400

> On Apr 26, 2017, at 15:22, Spencer Dawkins <[email-masked]> wrote:
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I've been waiting for this one, for a while. Thanks for finishing it. I'm
> a Yes, with comments.
> 
> I agree with EKR that there's a lot of general philosophy in this draft.
> I wouldn't ask that you pull all of it, but perhaps it could be trimmed
> down a bit.

The chairs discussed this and we’re going to not make a change here primarily because I fear we might go to far the other way and then we’re playing bring me rock.

> This is a nit, but in this text,
> 
>   Other efforts, for instance the W3C WEBRTC, Web Applications and
>   Device API working groups, focus on making standardized APIs and
>   interfaces available, within or alongside the HTML5 effort,
> 
> it would be nice to have the names here match what's on the W3C website.
> So, "Web Real-Time Communication", "Web Application Security", and
> "Device and Sensors", unless I'm guessing at the mapping wrong. It's also
> easy to read that text with "Web Applications and Device API" as a single
> working group, so using a comma after "Web Application Security" would be
> helpful.

I pulled the named from here:
https://www.w3.org/TR/tr-groups-all

The PR can be found here:
https://github.com/rtcweb-wg/rtcweb-overview/pull/23

> The term of art "floor control" is likely to be new to many readers in
> the future. Since it appears in a list of non-niche examples, maybe you
> don't need it at all?

I’m hoping people know how to google :) The wikipedia definition that popped up as the 1st result pretty much covers it.

> I'm not sure whether "let a thousand flowers bloom" is a reference to the
> Hundred Flowers campaign in 1956, but (1) that ended very badly for the
> bloomers, and (2) I could easily imagine the phrase tripping DPI
> filtering for a specific part of the Internet community. Maybe there's a
> better phrase?

There might be but that the phrase I’ve often heard to refer to “let the market sort it out".

> I'm not sure how tutorial you want section 4 to be, but I'd at least
> mention appropriate retransmission and in-order delivery, in addition to
> congestion control, since you get that with SCTP on the data channel.
> 
> 4.  Data transport
> 
>   Data transport refers to the sending and receiving of data over the
>   network interfaces, the choice of network-layer addresses at each
> end
>   of the communication, and the interaction with any intermediate
>   entities that handle the data, but do not modify it (such as TURN
>   relays).
> 
>   It includes necessary functions for congestion control: When not to
>   send data.
> 
> Or maybe you can just chop that sentence, because the next paragraph
> points to https://tools.ietf.org/html/draft-ietf-rtcweb-transports-06,
> anyway?

I just listed the additional SCTP functions:
https://github.com/rtcweb-wg/rtcweb-overview/pull/25/files

> I found the reference to MMUSIC WG in
> 
>   3.  When a new codec is specified, and the SDP for the new codec is
>       specified in the MMUSIC WG, no other standardization should be
>       required for it to be possible to use that in the web browsers.
> 
> to be odd. MMUSIC may be around forever, but this work might be
> refactored at some point in the future. Is the point that 
> 
>   3.  When SDP for a new codec is specified, 
>       no other standardization should be
>       required for it to be used in the web browsers.
> 
> Or is there another way to say this?

Fair enough, we can future proof the document with this change:
https://github.com/rtcweb-wg/rtcweb-overview/pull/27

> I'm also wondering if the statement is true for any WebRTC endpoint, not
> just browsers.

I’m not sure, but the main point of that entire bullet is that there’s no changes necessary to the API an not all endpoints need to implement the API on the browser does.

> In this text,
> 
>   WebRTC endpoints MUST implement the functions described in that
>   document that relate to the network layer (for example Bundle
>   [I-D.ietf-mmusic-sdp-bundle-negotiation], RTCP-mux [RFC5761] and
>   Trickle ICE [I-D.ietf-ice-trickle]), but do not need to support the
>   API functionality described there.
> 
> I would have thought these were related to the transport layer. No?

Maybe, but since these drafts/RFCs are about setting up the connection they do seem to fit in the “Connection Management” section ;)

spt