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.
So it should reference https://www.w3.org/TR/2021/REC-webrtc-20210126 There is a good list of the history of the W3C drafts for interested at https://www.w3.org/standards/history/webrtc > On Mar 29, 2022, at 6:39 AM, Christer Holmberg > <christer.holmberg=40ericsson....@dmarc.ietf.org> wrote: > > Hi, > > A couple of comments: > > First, in general, if we are going to update the reference version, we need > to verify that we don’t break anything. > > 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. > > 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. > > 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. > > Regards, > > Christer > > > > > > > > > From: Gen-art <gen-art-boun...@ietf.org> on behalf of Joel M. Halpern > <j...@joelhalpern.com> > Sent: Tuesday, March 29, 2022 6:08:37 AM > To: Sean Turner <s...@sn3rd.com> > Cc: last-c...@ietf.org <last-c...@ietf.org>; gen-art@ietf.org > <gen-art@ietf.org>; RTCWeb IETF <rtc...@ietf.org>; > draft-uberti-rtcweb-rfc8829bis....@ietf.org<draft-uberti-rtcweb-rfc8829bis....@ietf.org> > Subject: Re: [Gen-art] Genart last call review of > draft-uberti-rtcweb-rfc8829bis-02 > > 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. > > Yours, > Joel > > On 3/28/2022 10:47 PM, Sean Turner wrote: > > > > > >> On Mar 27, 2022, at 13:49, Joel Halpern via Datatracker <nore...@ietf.org> > >> 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 > >> > >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > >> > >> 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: > >> > >> > >> > > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > -- > last-call mailing list > last-c...@ietf.org > https://www.ietf.org/mailman/listinfo/last-call _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
