Re: [rtcweb] Genart last call review of draft-uberti-rtcweb-rfc8829bis-02

"Joel M. Halpern" <> Tue, 29 March 2022 03:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8746E3A10F5; Mon, 28 Mar 2022 20:08:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ANGrnfQwDkIB; Mon, 28 Mar 2022 20:08:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 373D53A10FD; Mon, 28 Mar 2022 20:08:41 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4KSDzX5BFqz1nsZP; Mon, 28 Mar 2022 20:08:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1648523320; bh=DcYab+dkIUYdYD7WMHeH5E1V8Uq/DITI0w8DL9KmtkM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=aoMDw0Os/YWfhwWl+6uj0fT3gN4Qgyy0zRg9L9F5uNnbYhNDQgopmfyaog4ov3b+k ClWSLcmTJoeTAOsIMOen/OlxDV8KkeSt8aYTysrUiMzWfBeYFWNit8X5TqJ4DShsWS brv3B2UT0cgYeTvEOZ3p6GxlrGupIwC+6euqfivE=
X-Quarantine-ID: <4UY_vdNSqjhT>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 4KSDzW6T5qz1nsHm; Mon, 28 Mar 2022 20:08:39 -0700 (PDT)
Message-ID: <>
Date: Mon, 28 Mar 2022 23:08:37 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
To: Sean Turner <>
Cc:,,, RTCWeb IETF <>
References: <> <>
From: "Joel M. Halpern" <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [rtcweb] Genart last call review of draft-uberti-rtcweb-rfc8829bis-02
X-Mailman-Version: 2.1.29
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: Tue, 29 Mar 2022 03:08:46 -0000

Thanks Sean.  I finally concluded that was the intent.  And I think 
technically it says so.
If you could look at making that more clear early, it would probably 
help those readers who are not as familiar with the cited W3C API.


On 3/28/2022 10:47 PM, Sean Turner wrote:
>> On Mar 27, 2022, at 13:49, Joel Halpern via Datatracker <> wrote:
>> Reviewer: Joel Halpern
>> Review result: Ready with Issues
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>> For more information, please see the FAQ at
>> <>.
>> Document: draft-uberti-rtcweb-rfc8829bis-02
>> Reviewer: Joel Halpern
>> Review Date: 2022-03-27
>> IETF LC End Date: 2022-04-05
>> IESG Telechat date: Not scheduled for a telechat
>> Summary: This document is ready for publication as a Proposed Standard.
>> However, there are some issues that should be considered before final approval.
>> Major issues: None
>> Minor issues:
>>     I found myself confused as a reader about one aspect of this document  The
>>     document seems to describe both the Interface to the JSEP and the details
>>     of what the underlying system must do in response to JSEP operations.  The
>>     later is described very well and clearly.  The former is described quite
>>     vaguely.  I suspect that the assumption is that the required parameters are
>>     described in the W3C documents.  But it is hard to tell, and the only
>>     formal reference is a vague citation in the introduction to an outdated W3C
>>     specification.  A little more clarity on how an implementor is supposed to
>>     know what actual interface objects, methods, and parameters they need to
>>     provide would be helpful.  Also, the reference should be updated to
>>     whatever is the current W3C specification.
> Will check on updating the reference. I would be floored if we couldn’t point to it.
> The basic idea here is that the W3C WebRTC spec is API and this is the protocol spec.
>> Nits/editorial comments: