From nobody Mon Oct 4 03:34:13 2021 Return-Path: X-Original-To: wish@ietfa.amsl.com Delivered-To: wish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8873A13C6 for ; Mon, 4 Oct 2021 03:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuLpar_9XPix for ; Mon, 4 Oct 2021 03:34:05 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3669F3A13C7 for ; Mon, 4 Oct 2021 03:34:05 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id x4so10767338pln.5 for ; Mon, 04 Oct 2021 03:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bPvD+W1iBYc6+HH0Qdn2FB1aEd1GOysKKJc19VtLv38=; b=SiINm97yIcs6GgpdmMDGzlQtVMWYkNeQNF4RcJ3xl/S/2BMUQjJ94jsuxCPYXCGD8I ThtRC7L7wuBttiUlz0soiPsCt1cSgOzr1ebIWgzIw9Uh9bK+yaEytZ16h9jDzXCRbRyv h+WZDGFhpeZgxvBk+n9Q3/+rUNbNUhBnFYQX6UcOMmEAaD9hJgp/R6mTSK5MVinBf/qM A0x/RKxErZWA4yi/m1MZ1BJIR8u5V+6HFSOIixLKhTgAanS8kWLWcyJrrjLsc9GWbOIZ fnayGK5H+43yej5Q/mvaoyVKXI0jRi8e6xnUUKhSsUIt0xoeU+XOHt0znUbt7/ieuxlf g76A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bPvD+W1iBYc6+HH0Qdn2FB1aEd1GOysKKJc19VtLv38=; b=46PeaQkr9Rx82VXEDW15r5xRSRpuyyvDxhljxh9DecbsFBH+OnGlX/v3pdU2MMRzQj GSkjncRyBMIniOm7OkS8LgjBfC4iyGtVx3drPWTL9a1iD3Bn/0sboLq0tQtTA/VikTMm XoyU5grSQp4Jrth8cmI3KNpElH4V3T4EXSV5x8IRccNw+Fx71Ih1N8EfhHC7nhav673T yQnh0mTW4lvqCKQ7FfWgq+YgkRFQ5I6I6akXt+PlgzuVCjmxgCKLGYnmQwdAulhie8lC Lumt9rx0O8fczPdWt/F/WSfJQ1OCiRh23vQqRRlK2FQID5XMTF6Ir48pX2aK9lertX96 24ig== X-Gm-Message-State: AOAM530WqD9y8ET2HanmfmgkZ2thGV/U0jWQEDFPwStNtBSL0cBksSdI lyodTTjVESt0jbSGFcAROZSSZtu0HK2bNkh6/th2Tk2juJQ= X-Google-Smtp-Source: ABdhPJwShDDt5/xBYI2RWRXEcKkFhgwvDxEhXOzl2Zm54GyUIgtj5Jc3LAZDEUnAL2GSoeu0Xi4kV8al23c4lPj50tI= X-Received: by 2002:a17:902:c3c1:b0:13e:d190:849b with SMTP id j1-20020a170902c3c100b0013ed190849bmr1680101plj.78.1633343644089; Mon, 04 Oct 2021 03:34:04 -0700 (PDT) MIME-Version: 1.0 References: <87r1d6tfks.wl-jch@irif.fr> In-Reply-To: <87r1d6tfks.wl-jch@irif.fr> From: Sergio Garcia Murillo Date: Mon, 4 Oct 2021 12:33:53 +0200 Message-ID: To: Juliusz Chroboczek Cc: WISH List Content-Type: multipart/alternative; boundary="000000000000b3c18b05cd84732d" Archived-At: Subject: Re: [Wish] New draft changes X-BeenThere: wish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: WebRTC Ingest Signaling over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 10:34:11 -0000 --000000000000b3c18b05cd84732d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El jue, 30 sept 2021 a las 14:26, Juliusz Chroboczek () escribi=C3=B3: > Thanks a lot for your work, Sergio. > > > If the WHIP client gathers additional candidates (via STUN/TURN) after > > the SDP offer is sent, it MUST send a STUN request > > I'm confused about this requirement. > > Suppose that the client gathers an initial set of candidates and gets the > media flowing. The ICE gatherer is still running in the background, and > produces new (presumably useless) candidates. What needs to be done with > these candidates in order to satisfy the requirement above? > Send a new STUN request from the new gathered candidates to the server ones. This is the standard behaviour anyway, so not sure if we should remove the phrase to avoid confusion. > > > As the HTTP PATCH request sent by a WHIP client may be received out of > > order by the WHIP resource, the WHIP resource MUST keep track of the > > previous values of the ICE username fragment and client used by the WHI= P > > client. If an HTTP PATCH request is received with a previously used ICE > > username fragment and password by the client, the WHIP endpoint SHALL > > not perform and ICE restart but reject the request with a 409 Conflict > > response instead. > > Is there consensus for this approach? It's not too onerous to implement, > but it requires potentially unbounded amounts of server-side per-session > state, which is always error-prone and difficult to debug. > We could relax the MUST to SHOULD. > > Presumably, the client knows whether it's requesting an ICE restart or > trickling a candidate. How difficult would it be for clients to > explicitly indicate whether an SDP fragment requests an ICE restart, > perhaps in an HTTP header or a custom SDP attribute? > We would need to extend the ABNF grammar of the sdp fragment and change the mechanisms in RFC8840. I am ok with that, but not sure if we are allowed to do that. > > WHIP clients SHALL support HTTP redirection via the 307 Temporary > > Redirect response code. > > Does this requirement apply to both the WHIP and the resource endpoint, o= r > just to the WHIP endpoint? I'm fine with either alternative, but I think > this should be made explicit. > I think this should be only applicable to the initial WHIP request. The url of the whip resource should be a final one. > > > the WHIP endpoint SHALL > > This document uses both MUST and SHALL, which, as far as I recall, mean > the same thing. I feel it would be less confusing if MUST were used > everywhere. > Fine for me too, not sure what are the best editorial practices though. > > > The WHIP Endpoing SHALL gather all the ICE candidates > > Typo. > Thanks, fixed! Best regards Sergio --000000000000b3c18b05cd84732d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
El jue, 30 sept 2021 a las 14:26, Jul= iusz Chroboczek (<jch@irif.fr>) es= cribi=C3=B3:
Tha= nks a lot for your work, Sergio.

> If the WHIP client gathers additional candidates (via STUN/TURN) after=
> the SDP offer is sent, it MUST send a STUN request

I'm confused about this requirement.

Suppose that the client gathers an initial set of candidates and gets the media flowing.=C2=A0 The ICE gatherer is still running in the background, a= nd
produces new (presumably useless) candidates.=C2=A0 What needs to be done w= ith
these candidates in order to satisfy the requirement above?

Send a new STUN request from the new gathered candidat= es to the server ones. This is the standard behaviour anyway, so not sure i= f we should remove the phrase to avoid confusion.
=C2=A0

> As the HTTP PATCH request sent by a WHIP client may be received out of=
> order by the WHIP resource, the WHIP resource MUST keep track of the > previous values of the ICE username fragment and client used by the WH= IP
> client. If an HTTP PATCH request is received with a previously used IC= E
> username fragment and password by the client, the WHIP endpoint SHALL<= br> > not perform and ICE restart but reject the request with a 409 Conflict=
> response instead.

Is there consensus for this approach?=C2=A0 It's not too onerous to imp= lement,
but it requires potentially unbounded amounts of server-side per-session state, which is always error-prone and difficult to debug.
=

We could relax the MUST to SHOULD.
=C2=A0

Presumably, the client knows whether it's requesting an ICE restart or<= br> trickling a candidate.=C2=A0 How difficult would it be for clients to
explicitly indicate whether an SDP fragment requests an ICE restart,
perhaps in an HTTP header or a custom SDP attribute?
<= br>
We would need to extend the ABNF grammar of the sdp fragment = and change the mechanisms in=C2=A0RFC8840.=C2=A0

I= am ok with that, but not sure if we are allowed to do that.
=C2= =A0
> WHIP clients SHALL support HTTP redirection via the 307 Temporary
> Redirect response code.

Does this requirement apply to both the WHIP and the resource endpoint, or<= br> just to the WHIP endpoint?=C2=A0 I'm fine with either alternative, but = I think
this should be made explicit.

I think t= his should be only applicable to the initial WHIP request. The url of the w= hip resource should be a final one.
=C2=A0

> the WHIP endpoint SHALL

This document uses both MUST and SHALL, which, as far as I recall, mean
the same thing.=C2=A0 I feel it would be less confusing if MUST were used everywhere.

Fine for me too, not sure w= hat are the best editorial practices though.
=C2=A0

> The WHIP Endpoing SHALL gather all the ICE candidates

Typo.

Thanks, fixed!

Best regards
Sergio
--000000000000b3c18b05cd84732d-- From nobody Wed Oct 6 08:52:23 2021 Return-Path: X-Original-To: wish@ietfa.amsl.com Delivered-To: wish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07063A1E14 for ; Wed, 6 Oct 2021 08:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWIv5Ubcf8eR for ; Wed, 6 Oct 2021 08:52:16 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD56A3A1C5A for ; Wed, 6 Oct 2021 08:52:14 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 196Fq9n5013574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Oct 2021 17:52:09 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 196Fq9UK000623; Wed, 6 Oct 2021 17:52:09 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 982D2B0CAF; Wed, 6 Oct 2021 17:52:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id FaIj16ergc26; Wed, 6 Oct 2021 17:52:07 +0200 (CEST) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 88653B0CAB; Wed, 6 Oct 2021 17:52:07 +0200 (CEST) Date: Wed, 06 Oct 2021 17:52:07 +0200 Message-ID: <87zgrmb17c.wl-jch@irif.fr> From: Juliusz Chroboczek To: Sergio Garcia Murillo Cc: WISH List In-Reply-To: References: <87r1d6tfks.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 06 Oct 2021 17:52:09 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 06 Oct 2021 17:52:09 +0200 (CEST) X-Miltered: at korolev with ID 615DC629.004 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 615DC629.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 615DC629.004 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 615DC629.003 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 615DC629.004 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 615DC629.003 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [Wish] New draft changes X-BeenThere: wish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: WebRTC Ingest Signaling over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 15:52:22 -0000 >>> If the WHIP client gathers additional candidates (via STUN/TURN) after >>> the SDP offer is sent, it MUST send a STUN request >> I'm confused about this requirement. > This is the standard behaviour anyway, so not sure if we should remove the > phrase to avoid confusion. Yes, please remove it. >>> As the HTTP PATCH request sent by a WHIP client may be received out of >>> order by the WHIP resource, the WHIP resource MUST keep track of the >>> previous values of the ICE username fragment and client used by the WHIP >>> client. If an HTTP PATCH request is received with a previously used ICE >>> username fragment and password by the client, the WHIP endpoint SHALL >>> not perform and ICE restart but reject the request with a 409 Conflict >>> response instead. >> Is there consensus for this approach? It's not too onerous to implement, >> but it requires potentially unbounded amounts of server-side per-session >> state, which is always error-prone and difficult to debug. > We could relax the MUST to SHOULD. I'm not sure how that would work. If the server receives an SDP fragment, and cannot distinguish between an ICE restart and an out-of-order ICE candidate, how should it behave? >> Presumably, the client knows whether it's requesting an ICE restart or >> trickling a candidate. How difficult would it be for clients to >> explicitly indicate whether an SDP fragment requests an ICE restart, >> perhaps in an HTTP header or a custom SDP attribute? > We would need to extend the ABNF grammar of the sdp fragment and change the > mechanisms in RFC8840. > > I am ok with that, but not sure if we are allowed to do that. Alternatively, we could encode the information in a custom HTTP header, or as a query in the URL. I don't understand REST well, and I'm not sure what the consequences are. -- Juliusz From nobody Thu Oct 7 15:10:08 2021 Return-Path: X-Original-To: wish@ietfa.amsl.com Delivered-To: wish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8278D3A0FBD for ; Thu, 7 Oct 2021 15:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k03KgXDJLTRR for ; Thu, 7 Oct 2021 15:10:01 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C933A0FB6 for ; Thu, 7 Oct 2021 15:10:00 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id y28so8452973vsd.3 for ; Thu, 07 Oct 2021 15:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hEDSrmx0T+grNjYX640i6agfwRAq1RCWPsl3kx+C/H0=; b=JJ2WmkOXcEZVVzqHwVwF0N3ECe12ZBg3rMxw6JpA/FVoK4H0PsG6e5yYTPViFVAKFb MN/5Xg+iJIH5isFRuUikcyheua2uICvnsNdVUiQ7t8qGdy9MHwMiePgBz8fQhWazAbCn QkTcSvv7CYy1+SIecruZ4ItAdg63gcG/KiBzsO6yoJkDzfrx++Nj3g4jl9aLI1zOEVxN U5wSFUyDXPMeDv+1K9URsFE7ktXmvS0lYfpAw3VIEu4fs62Ipk6SglP+vsXulYKvOAQr nL6/aF891L030+rxmA1U9yI+WzuT+mfIKSOGZSmTVnmkUHrP6XuCGB+7mYhunFi9zbjW Kywg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hEDSrmx0T+grNjYX640i6agfwRAq1RCWPsl3kx+C/H0=; b=IwsG1NDhqHClWE0vUvM7scHI4k832dwablIho8NNXi2rRASHrXSj1X+kihIUgbPVJe sUZiLX4KKtMsS431WY7hMsfGIrRd4PUymwOCnlAqzNlQ+kMULqQExbsgi1hW00v2l5Ai bTVJfzr6gZ/SuR4368tp42HUDQOjUEF4QxIbMMhwATkqgkjPIn0HbLzfzrWrLzSJmqTh 45OSAdVcPntGiX/G40if5Y7AnGalP+bEYeObpegh2kVJLdfWqDqC1SuI2KpoFNyI456N TDs79uGESplzMomgRT0Mbld5peXfbBDK0TTOippsrsh5uh2x5LjAeQ3fx6s8prwzWYaD rS1g== X-Gm-Message-State: AOAM532xbtbSc/8FGa2hCdMityo9FJASDGO65SJSagBogS2iQI4tXa1p EVFX2GoYycUSLvyFiXvvCJ+ad8xJaW4Rf7tz8cau/Moo X-Google-Smtp-Source: ABdhPJzKNFGJvL2wG2xmNufxNScQDyATvT81Z9M7yhctLcf9flpOgWebsy2LB2IdHuMUj68JYyBLBk3NylaNAl6ZT/Q= X-Received: by 2002:a67:e19c:: with SMTP id e28mr7576867vsl.38.1633644599660; Thu, 07 Oct 2021 15:09:59 -0700 (PDT) MIME-Version: 1.0 References: <87o893vuz4.wl-jch@irif.fr> In-Reply-To: <87o893vuz4.wl-jch@irif.fr> From: Spencer Dawkins at IETF Date: Thu, 7 Oct 2021 17:09:33 -0500 Message-ID: To: Juliusz Chroboczek Cc: Sergio Garcia Murillo , WISH List Content-Type: multipart/alternative; boundary="0000000000000d53e705cdca863d" Archived-At: Subject: Re: [Wish] Authentication for resource url X-BeenThere: wish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: WebRTC Ingest Signaling over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2021 22:10:06 -0000 --0000000000000d53e705cdca863d Content-Type: text/plain; charset="UTF-8" Just chiming in for one point - On Wed, Sep 8, 2021 at 12:27 PM Juliusz Chroboczek wrote: > > I think we have the following options: > > - Use the same mechanism/info as the initial request to the whip url > (i.e. > > sending the Authentication header with the same bearer token) > > - Returning a randomized opaque unique url > > - Allow using both? > > I think this is better left unspecified in the normative part of the > document, but should be explained in detail in the Security Considerations > section or in an informative appendix. > I can't speak to where the explanation should be, but Security Considerations are pretty much always normative. If you're thinking "informative", you'd surprise fewer people if you put that in an appendix (marked "informative"). IMO, of course. Best, Spencer > -- Juliusz > > -- > Wish mailing list > Wish@ietf.org > https://www.ietf.org/mailman/listinfo/wish > --0000000000000d53e705cdca863d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just chiming in for one point -=C2=A0
On W= ed, Sep 8, 2021 at 12:27 PM Juliusz Chroboczek <jch@irif.fr> wrote:
> I think we have the following options:
>=C2=A0 - Use the same mechanism/info as the initial request to the whip= url (i.e.
> sending the Authentication header with the same bearer token)
>=C2=A0 - Returning a randomized opaque unique url
>=C2=A0 - Allow using both?

I think this is better left unspecified in the normative part of the
document, but should be explained in detail in the Security Considerations<= br> section or in an informative appendix.

= I can't speak to where the explanation should be, but Security Consider= ations are pretty much always normative. If you're thinking "infor= mative", you'd surprise fewer people if you put that in an appendi= x (marked "informative").

IMO, of course= .=C2=A0

Best,

Spencer
=C2=A0
-- Jul= iusz

--
Wish mailing list
Wish@ietf.org
https://www.ietf.org/mailman/listinfo/wish
--0000000000000d53e705cdca863d-- From nobody Fri Oct 15 15:44:17 2021 Return-Path: X-Original-To: wish@ietf.org Delivered-To: wish@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED90F3A0DE0; Fri, 15 Oct 2021 15:34:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: superuser@gmail.com, wish@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163433724495.17026.12256008905387495121@ietfa.amsl.com> Date: Fri, 15 Oct 2021 15:34:04 -0700 Archived-At: Subject: [Wish] wish - Requested session has been scheduled for IETF 112 X-BeenThere: wish@ietf.org X-Mailman-Version: 2.1.29 List-Id: WebRTC Ingest Signaling over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 22:34:24 -0000 Dear Nils Ohlmeier, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. wish Session 1 (1:00 requested) Friday, 12 November 2021, Session II 1430-1530 Room Name: Room 2 size: 502 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/112/sessions/wish.ics Request Information: --------------------------------------------------------- Working Group Name: WebRTC Ingest Signaling over HTTPS Area Name: Applications and Real-Time Area Session Requester: Nils Ohlmeier Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 40 Conflicts to Avoid: People who must be present: Murray Kucherawy Nils Ohlmeier Sean Turner Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Oct 20 15:25:49 2021 Return-Path: X-Original-To: wish@ietf.org Delivered-To: wish@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C14BA3A08E5; Wed, 20 Oct 2021 15:25:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: wish@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: wish@ietf.org Message-ID: <163476874556.6932.2950902680208504625@ietfa.amsl.com> Date: Wed, 20 Oct 2021 15:25:45 -0700 Archived-At: Subject: [Wish] I-D Action: draft-ietf-wish-whip-01.txt X-BeenThere: wish@ietf.org X-Mailman-Version: 2.1.29 List-Id: WebRTC Ingest Signaling over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 22:25:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WebRTC Ingest Signaling over HTTPS WG of the IETF. Title : WebRTC-HTTP ingestion protocol (WHIP) Authors : Sergio Garcia Murillo Alexandre Gouaillard Filename : draft-ietf-wish-whip-01.txt Pages : 13 Date : 2021-10-20 Abstract: While WebRTC has been very sucessful in a wide range of scenarios, its adoption in the broadcasting/streaming industry is lagging behind. Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media into a streaming service using WebRTC and so content providers still rely heavily on protocols like RTMP for it. These protocols are much older than WebRTC and by default lack some important security and resilience features provided by WebRTC with minimal overhead and additional latency. The media codecs used for ingestion in older protocols tend to be limited and not negotiated. WebRTC includes support for negotiation of codecs, potentially alleviating transcoding on the ingest node (wich can introduce delay and degrade media quality). Server side transcoding that has traditionally been done to present multiple renditions in Adaptive Bit Rate Streaming (ABR) implementations can be replaced with simulcasting and SVC codecs that are well supported by WebRTC clients. In addition, WebRTC clients can adjust client- side encoding parameters based on RTCP feedback to maximize encoding quality. Encryption is mandatory in WebRTC, therefore secure transport of media is implicit. This document proposes a simple HTTP based protocol that will allow WebRTC based ingest of content into streaming servics and/or CDNs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-wish-whip/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-wish-whip-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 28 12:10:59 2021 Return-Path: X-Original-To: wish@ietfa.amsl.com Delivered-To: wish@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5263A0FE1 for ; Thu, 28 Oct 2021 12:10:57 -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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0AhQPB1E0Nt for ; Thu, 28 Oct 2021 12:10:53 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EE513A0FDE for ; Thu, 28 Oct 2021 12:10:53 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id h16so2361807qtk.0 for ; Thu, 28 Oct 2021 12:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=NsToqA589ya+kHj2O26QMW1r/I/eg8EZ6WF6KaDweP4=; b=WOoNoNWMga7OER7Ttv63uccDw9Wd/Q5uHek3rMRd+hOhn/Vmqx+/6t+lLHPCRRF8XH MCQqBf74CRpaDdhw76Fgm7mgY5LclWZSpLyiaysRV32vZon8/w9R7EggB3fto9RaTKru YOGq0tC7w7b0xdUN5k5qpBxlBMThZLvF3xgbI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=NsToqA589ya+kHj2O26QMW1r/I/eg8EZ6WF6KaDweP4=; b=Rq47tcOKoev1jDl+uqC9N5a+TacYY+t3wrUW6CQ7ELSU+7V/skU/3GvrSMQggITQBJ X+1XtVGMIocP+4VH2bzgrJJCj4arwr4Y0JT2MF71Mbr89y78RNBXZpgxl5hiHTW1tcuL CBp72md00DTbtd4yJMRHvNGqgz/V4BC6cweDG9LgQnNuxj3liAIamsO+HRWrZ8ewwy8s OLkeMBV5GcnAwrTRrN8CETefJ7R09ypAB6Xv2t+K//KA0DAYrFEMCXxwhnPGH8aljZF4 nWAPounrYITZoqM30/OU7pn5hOlF3rhhalk8N9tWwWRuHbujeQwNgSlfLgA8U2SkCm/F z64g== X-Gm-Message-State: AOAM533duUT0jtwDAkYDaYhBHK6fsQz1ibBmu/CTiJZsBCJF9PHNflTd fUGKjHq5VUtXFaj1reiyyKDSd2xn84u8Rw== X-Google-Smtp-Source: ABdhPJyEMqW/dSgFQPdIuYZSTNj2o/6V7SEtA8dBUoLo0zKSqwI+OEBDwI3vbsNaVyyqpJ2qArjVUA== X-Received: by 2002:a05:622a:614:: with SMTP id z20mr6718826qta.94.1635448250181; Thu, 28 Oct 2021 12:10:50 -0700 (PDT) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id j20sm2678288qtj.72.2021.10.28.12.10.49 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Oct 2021 12:10:49 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-Id: <20B00516-AB95-4ECB-84E6-7BF4692E3EB8@sn3rd.com> Date: Thu, 28 Oct 2021 15:10:48 -0400 To: WISH List X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: [Wish] wish@ietf112 X-BeenThere: wish@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: WebRTC Ingest Signaling over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2021 19:10:58 -0000 Hi! We have a meeting time scheduled for Friday, 12 November 2021 from = 1430-1530 (UTC). Please send in your agenda topics along with how much = time you think you will need to wish-chairs@ietf.org. Cheers, Nils and Sean=