From nobody Tue Apr 26 18:39:12 2022 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00175C19E0D3 for ; Tue, 26 Apr 2022 18:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rilzm0Lys5Ya for ; Tue, 26 Apr 2022 18:39:06 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 ietfa.amsl.com (Postfix) with ESMTPS id D0FF9C185767 for ; Tue, 26 Apr 2022 18:39:06 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id b189so342590qkf.11 for ; Tue, 26 Apr 2022 18:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RtbPHn+6Z7jah7Ak/5QyPb0opk5IT2F1XH3Dl2TVQ1c=; b=gyEeTHuFaMqw7lqQtvS5P7cOLaP1fFT0R3oMt/y6d18yE024GZMcW7KdcedL8tWHWF YYlxKlhwKFWJtR0C41d95xXg5H8XekiecvWW9JFr5nsZWNNdDMh0PNfRRIXvaYBSfpkC YWHCSyTBpguusTh9VPlY6LQzd7i4mzoIu6b5A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RtbPHn+6Z7jah7Ak/5QyPb0opk5IT2F1XH3Dl2TVQ1c=; b=H8aS8Unb2VVOiAbMcNIHYOzfABpH94iZtg8XSC0f5tTIhpQNRgTeY3/+uhzlMYera8 SEQ5agy71OVn7GLdM+plGfgVOgMc9UrWMlMuIFcpko1bXl+pvfMhXctR5Gkuk3EObAXS 0SY5DEFo3Voqn+9/Lvr77KymM8LWF67w+SUxGE7FRLHFMVpfwwkc0PMGSySrsnQDN8vm NFjJmkCXnPhhk/YYD+vKdrpmhmXjeDgt3nERfNdY/YXtwtNWy3FwQ6Vw3SHtbFGHrTu8 6b7D/LS1ruzrm8vTiTJsbZiRsZn0SqScDeKyn0bW0fhQPywDB9M6SE99BsDcyfqx9YLu RFVg== X-Gm-Message-State: AOAM5336MS3RJmSHxIrZkE6z0hhEfvmYqcJyonADYUaSmYv8927ZDyx9 7lxnETfylzcOkRDsjh9ik7rnOQ== X-Google-Smtp-Source: ABdhPJxNd3mdh9RFaaiZ7FGpQg/MFaHz8LVuVuo5tRH3IJZcKOpenDoQW/O7b3SMPg2fOFsBSRpr4w== X-Received: by 2002:ae9:e518:0:b0:69f:8dc5:c173 with SMTP id w24-20020ae9e518000000b0069f8dc5c173mr25359qkf.421.1651023545619; Tue, 26 Apr 2022 18:39:05 -0700 (PDT) Received: from smtpclient.apple (pool-72-83-85-4.washdc.east.verizon.net. [72.83.85.4]) by smtp.gmail.com with ESMTPSA id f25-20020a05620a15b900b0069f78e60ee9sm1717012qkk.105.2022.04.26.18.39.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Apr 2022 18:39:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Sean Turner In-Reply-To: Date: Tue, 26 Apr 2022 21:39:02 -0400 Cc: Joel Halpern , "last-call@ietf.org" , "gen-art@ietf.org" , RTCWeb IETF , "draft-uberti-rtcweb-rfc8829bis.all@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <39CFF823-5113-4B26-ADD6-05830C5D37DF@sn3rd.com> References: <164840334560.25727.8727238035250838155@ietfa.amsl.com> <320CCABF-5283-4B07-B637-FC03F582CA2D@sn3rd.com> <72fa004c-cdd8-807d-1ba6-4ba2b3b15969@joelhalpern.com> <3BD1DD31-5248-4B91-B06E-F6376E694492@cisco.com> To: Christer Holmberg , "Cullen Jennings (fluffy)" , Harald Tveit Alvestrand X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [rtcweb] [Last-Call] [Gen-art] Genart last call review of draft-uberti-rtcweb-rfc8829bis-02 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.34 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: Wed, 27 Apr 2022 01:39:11 -0000 Hi! I would really love to give our AD a revised version of this I-D = soon. > On Apr 17, 2022, at 12:37, Christer Holmberg = wrote: >=20 > Hi, >=20 >> I feel very strongly that we must reference a stable version or else = there is no way to know what is reviewed. The w3c spec was not approved = before and was a draft >> so it was hard but at this point I think the REC version is the = correct references.=20 >=20 > I don't object to referencing a specific version - I actually agree. >=20 > My question is why JSEP uses an INFORMATIVE WebRTC reference WITH a = version, while other RTCWEB RFCs use NORMATIVE WebRTC references WITHOUT = a version... I didn=E2=80=99t do an exhaustive search, but I did note that RFCs 8825, 8827, and 8834 refer to the the W3C specification normatively = as follows: https://www.w3.org/TR/webrtc/ There is no chance that there is any energy whatsoever to go back and = change those three to refer to a specific version. So I think we will = need to call those done. For this I-D, I originally submitted the following PR to update the = reference to the final recommendation. I have updated that PR to also = move the reference to be normative. See: https://github.com/rtcweb-wg/jsep/pull/1024 Is there any objection to moving the reference to normative? >> So it should reference https://www.w3.org/TR/2021/REC-webrtc-20210126 >=20 > RFC 8829 references https://www.w3.org/TR/2020/PR-webrtc-20201215/. I = just want to verify that there is no text etc in 8829bis that is not = aligned with 20210126. Harald or Cullen can one of you comment on this? The vast majority of = PRs merged into the 202110126 version were marked as editorial. spt > Regards, >=20 > Christer >=20 >=20 >=20 >> On Mar 29, 2022, at 6:39 AM, Christer Holmberg = wrote: >>=20 >> Hi, >>=20 >> A couple of comments: >>=20 >> First, in general, if we are going to update the reference version, = we need to verify that we don=E2=80=99t break anything. >>=20 >> Second, most of the RTCWEB RFCs referencing the WebRTC spec seem to = reference *without* a version (i.e., https://www.w3.org/TR/webrtc/). = Many RFCs also reference to RFC 8825 for WebRTC, and RFC 8825 also = reference WebRTC without a version. >>=20 >> So, is there a reason why we would use a version in JSEP, while not = in other RFCs? Note that often the WebRTC reference is Normative. >>=20 >> I do understand that JSEP is very closely linked to WebRTC, why there = might be a need to reference a given version. But, then again, we need = to make sure that updating the version does not break anything. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> From: Gen-art on behalf of Joel M. = Halpern=20 >> >> Sent: Tuesday, March 29, 2022 6:08:37 AM >> To: Sean Turner >> Cc: mailto:last-call@ietf.org ; = mailto:gen-art@ietf.org=20 >> ; RTCWeb IETF ;=20 >> = mailto:draft-uberti-rtcweb-rfc8829bis.all@ietf.org> mailto:9bis.all@ietf.org> >> Subject: Re: [Gen-art] Genart last call review of=20 >> draft-uberti-rtcweb-rfc8829bis-02 >>=20 >> Thanks Sean. I finally concluded that was the intent. And I think=20= >> technically it says so. >> If you could look at making that more clear early, it would probably=20= >> help those readers who are not as familiar with the cited W3C API. >>=20 >> Yours, >> Joel >>=20 >> On 3/28/2022 10:47 PM, Sean Turner wrote: >>>=20 >>>=20 >>>> On Mar 27, 2022, at 13:49, Joel Halpern via Datatracker = wrote: >>>>=20 >>>> Reviewer: Joel Halpern >>>> Review result: Ready with Issues >>>>=20 >>>> I am the assigned Gen-ART reviewer for this draft. The General Area=20= >>>> Review Team (Gen-ART) reviews all IETF documents being processed by=20= >>>> the IESG for the IETF Chair. Please treat these comments just like=20= >>>> any other last call comments. >>>>=20 >>>> For more information, please see the FAQ at >>>>=20 >>>> . >>>>=20 >>>> 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 >>>>=20 >>>> Summary: This document is ready for publication as a Proposed = Standard. >>>> However, there are some issues that should be considered before = final approval. >>>>=20 >>>> Major issues: None >>>>=20 >>>> 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. >>>=20 >>> Will check on updating the reference. I would be floored if we = couldn=E2=80=99t point to it. >>>=20 >>> The basic idea here is that the W3C WebRTC spec is API and this is = the protocol spec. >>>=20 >>>> Nits/editorial comments: >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> Gen-art mailing list >> mailto:Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art >> -- >> last-call mailing list >> mailto:last-call@ietf.org >> https://www.ietf.org/mailman/listinfo/last-call >=20