Re: [rtcweb] WGLC: draft-ietf-rtcweb-overview

Harald Alvestrand <> Fri, 09 December 2016 15:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5329A12946C for <>; Fri, 9 Dec 2016 07:32:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ixay0u3WTnVI for <>; Fri, 9 Dec 2016 07:32:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA5871293FF for <>; Fri, 9 Dec 2016 07:32:02 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10E607C42D7; Fri, 9 Dec 2016 16:32:01 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s3fjEr_HRtIE; Fri, 9 Dec 2016 16:32:00 +0100 (CET)
Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by (Postfix) with ESMTPSA id D16F67C42D6; Fri, 9 Dec 2016 16:31:59 +0100 (CET)
To: Magnus Westerlund <>, Sean Turner <>,
References: <> <>
From: Harald Alvestrand <>
Message-ID: <>
Date: Fri, 09 Dec 2016 16:31:58 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [rtcweb] WGLC: draft-ietf-rtcweb-overview
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Dec 2016 15:32:11 -0000

Thank you for the review!

Den 09. des. 2016 15:35, skrev Magnus Westerlund:
> Hi,
> I have reviewed the overview document and have the following comments:
> 1. Section 1:
>    As the available bandwidth has increased, and as processors an other
>    hardware has become ever faster, the barriers to participation have
>    decreased, and it has become possible to deliver a satisfactory
>    experience on commonly available computing hardware.
> "processors an other" i guess it should say "and"
> 2. Section 2.2:
>    o  A Javascript API specification, done in the W3C
>       [W3C.WD-webrtc-20120209][W3C.WD-mediacapture-streams-20120628]
> "A"? Shouldn't this say a "A set of Javascript API specifications, ..."
> as there are multiple APIs? I know such reformulation would impact the
> next couple of paragraphs at least. But, maybe some other way of
> acknowledging the fact that there are multiple API parts?

Actually both the IETF effort and the W3C effort consists of lots of
moving parts. Would "A Javascript API, defined by a set of
specifications [cite]" scan better?

> 3. Section 2.2:
> "and the Javascript API defined above."
> I see a issue with pointing to the specific API specs above. This as if
> there are other API relatizations defined, even if compatible they are
> not considered WebRTC Browser. I would suggest, simply drop "defined
> above".

Right, that's what I intended to say, and what I think the WG wanted.
Unless we can point to a specific API, there's no way to differentiate
between a WebRTC browser and a WebRTC non-browser.

For a currently interesting example - Edge implements the ORTC API,
which they believe is implementing the WebRTC protocols, and offering an
API to them. But it is not the WebRTC API.

So at the moment, I'd want to claim that Edge is a WebRTC non-browser.
Edge with the 1.0 shim would be a WebRTC browser - and when  Edge
implements the WebRTC 1.0 natively, Edge would turn into a WebRTC browser.

There are also lots of devices using a C++ API to WebRTC-implementing
libraries. These cannot make the API security guarantees that the
rtcweb-security drafts depend on for their design. So I consider it
appropriate to classify them as WebRTC non-browsers, too.

If this isn't the consensus of the group, we can change it. But it is
what I intended to write.

> 4. On the completeness of the specification
> Looking at the current set of RTCWeb WG documents, one sees that there
> are some that are not referenced:
> draft-ietf-rtcweb-alpn-04
> draft-ietf-rtcweb-fec-04    
> draft-ietf-rtcweb-ip-handling-02

All of these are indirectly referenced. ALPN is referenced by
-transport-, and FEC is referenced by -rtp-usage. ip-handling is
referenced by -jsep-.

Is it necessary to reference them directly? If so, where would you
suggest that the overview needs text that references them?

> The above are referenced by mentioned documents
> draft-ietf-rtcweb-sdp-02

That document is only examples. I'm happy to have it only indirectly

> Is not referenced by any document currently. Thus the question is if one
> needs to include a reference in some suitable place for this document,
> or if it is fine as a stand alone one. Considering that it is an
> informational explanation document, it may not need to be included, but
> I have to raise the question if it should be included at least as an
> informational reference in Overview, or somewhere else?
> Conclusion: I think this document is ready for publication request when
> the above issues has been considered.
> Cheers
> Magnus Westerlund
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto:
> ----------------------------------------------------------------------
> _______________________________________________
> rtcweb mailing list