jiebi/CodeConvo huggingface dataset:
Change:
This was either in error, or could refer to "JWT" instead.
There are multiple references to a token that are unclear: ...
The first is just a mistake; a relic of a previous version. It can be removed. The second refers to JWT. I'll fix that.

Discussion:
When a push subscription has been associated with an application server, the request for push message delivery MUST include proof of <del> possession for the associated private key or token that was used when creating the push subscription. </del> <ins> possession for the associated private key that was used when creating the push subscription. </ins> A push service MUST reject a message that omits mandatory credentials with a 401 (Unauthorized) status code.  A push service MAY reject a

the public key used to sign the JWT doesn't match the one that was included in the creation of the push message. <del> A push subscription that is not restricted to a particular key MAY still validate a token that is present, except for the last check.  A push service MAY then reject a request if the token is found to be invalid. </del> In theory, since the push service was given a public key, the push message request could omit the public key.  On balance, requiring the key keeps things simple and it allows push services to
Change:
LGTM, thank you! Is the addition required because of the following language in 7519?
Well, that's a good reason, but is the main reason. See the discussion leading up to that.
I read the thread and issue; reading JWT, there was nothing prohibiting providing additional fields (aside from that SHOULD), so I was wondering if specifying this is a normative requirement or a good clarification :-).
If I may, clarification is always good. One should presume that the readers of these specs may not be fully versed in the subtle details of other, reliant specs, so a bit of useful info like this might be very welcome.
As noted in the arguments of , there is a need for an "extra data" field which would be used by the parties using the VAPID claims. This data would contain information useful to the publisher of the claim (e.g. the originating server ID, transaction ID, or other possibly VAPID consumer opaque data). This extra data ("vapid-ext" ?) field would allow consistent, predictable definition rather than a set of 'one-offs' that may be difficult to find or ignored by operators.
Started thread: URL JR requests that we allow the inclusion of extra stuff in a vapid token: URL field which would be used by the parties using the VAPID claims. This data would contain information useful to the publisher of the claim (e.g. the originating server ID, transaction ID, or other possibly VAPID consumer opaque data). This extra data ("vapid-ext" ?) field would allow consistent, predictable definition rather than a set of 'one-offs' that may be difficult to find or ignored by operators. <<< I think that the general idea is fine. Better this than trying to pack the "sub" field with extra stuff. JR, would it suffice to point out that the (or even ) claims can be added to the token? Allowing multiple fields gives the application server a fair bit more flexibility. If that's OK, we should point out that this is possible so that push services don't lose the extra data because they aren't aware that it might exist.

Discussion:
2.2. <ins> An application server MAY include additional claims using public or private names (see Sections 4.2 and 4.3 of RFC7519).  Since the JWT is in a header field, the size of additional claims SHOULD be kept as small as possible. 2.3. </ins> An application server requests the delivery of a push message as described in I-D.ietf-webpush-protocol.  If the application server wishes to self-identify, it includes an Authorization header field
Change:
attn: NAME
Thanks !
From NAME authenticated with VAPID, all subsequent subscribe, unsubscribe, ack or monitor requests associated with the same pushset MUST be authenticated with VAPID with same public key" already needs to have code to handle EC for the e2e encryption. The main concern is an attacker 'acking' or unsubscribing - since the messages are e2e encrypted they can't read it.
This looks good to me.

Discussion:
this authentication scheme. This authentication scheme is intended for use by an application <del> server when using the webpush protocol I-D.ietf-webpush-protocol, but it could be used in other contexts if applicable. </del> <ins> server when using the Web Push protocol I-D.ietf-webpush-protocol, but it could be used in other contexts if applicable. </ins> 4.
Change:
I know that it's the devil, but JSON is the obvious choice here.
Why would it be obvious ? application/x-www-form-urlencoded or a request parameter ?
It's an obvious choice given the proprietary precedence in the industry. I can't really judge the appropriateness of using JSON as opposed to an alternative -- this change LGTM assuming it is. Since the UA chooses the PS, there is no need for encryption. JSON provides good extensibility for additional (proprietary) data that may have to be transmitted over this channel.
At least it's not xml... I don't mind json - just didn't think it is so obvious. It does open an important question: will the user be allowed to pass more information to the push service (voluntarily) ? But +1 on this change.
Probably, but I don't want to think about that just yet :)

Discussion:
of the resulting subscription to application servers that are able to provide proof of possession for the corresponding private key. <del> This public key is then added to the request to create a push subscription as described in key.  The Crypto-Key header field includes exactly one ECDSA public key on the P-256 curve, encoded in the uncompressed form X9.62 and base64url RFC7515.  The example in ex-restrict shows a restriction to the key used in ex-push: </del> <ins> The public key is then added to the request to create a push subscription.  The push subscription request is extended to include a body.  The body of the request is a JSON object as described in RFC7159.  A "vapid" member is added to this JSON object, containing the public key on the P-256 curve, encoded in the uncompressed form X9.62 and base64url encoded RFC7515.  The MIME media type of the body is set to "application/json". The example in ex-restrict shows a restriction to the key used in ex- push.  Extra whitespace is added to to meet formatting constraints. </ins> An application might use the Web Push API API to provide the user agent with a public key.

6. <del> 6.1. This registers the "vapid" authentication scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" established in RFC7235. </del> <ins> This document registers the "vapid" authentication scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" established in RFC7235. </ins> vapid

This scheme is origin-server only and does not define a challenge. <del> 6.2. </del> <ins> 6.1. </ins> This creates a "Vapid Authentication Scheme Parameters" registry for parameters to the "vapid" authentication scheme.  This registry is

of the parameter. This registry initially contains the following entries: <del> 6.3. This registers a "vapid" parameter for the Crypto-Key header field in the "Hypertext Transfer Protocol (HTTP) Crypto-Key Parameters" established in I-D.ietf-httpbis-encryption-encoding. vapid An ECDSA public key for use in validating vapid tokens restrict of this document </del>
Change:
From NAME Simulcast and scalable video coding Both Simulcast [RFC8853] and Scalable Video Coding (SVC), including K-SVC (also known as "S modes", in which multiple encodings are sent on the same SSRC), MAY be supported by both the Media Servers and WHIP clients through negotiation in the SDP offer/answer. [BA] K-SVC and “S” modes are different. K-SVC denotes the KEY and KEY_SHIFT modes, whereas “S” modes denote the encapsulation of multiple encodings within a single SSRC, as is supported in VP9 and AV1. Diagrams of the various modes are included in the WebRTC-SVC specification: URL Also, SVC is not negotiated within Offer/Answer in WebRTC. It is something that the encoder can just turn on. At least for temporal modes (L1T2, L1T3) ingester support can often be taken for granted. While the VP9 and AV1 specifications require a compliant decoder to be able to decode any mode than an encoder can encode, in practice there are VP9 and AV1 hardware decoders that cannot decode spatial scalability because they do not support spatial references (e.g. a P-frame at a higher resolution than the P or I frame that it references). This nasty little “wrinkle” required us to define the “spatialScalability” attribute in Media Capabilities, to allow applications to discover whether a (hardware) decoder supports spatial scalability or not: Media Capabilities URL Not sure if you want to get into this in the specification. Issues are most likely to be encountered where hardware-based transcoders are used (but in that scenario, spatial scalability probably wouldn’t be relevant anyway),

Discussion:
4.6. <del> Both Simulcast RFC8853 and Scalable Video Coding (SVC), including K-SVC (also known as "S modes", in which multiple encodings are sent on the same SSRC), MAY be supported by both the Media Servers and WHIP clients through negotiation in the SDP offer/answer. </del> <ins> Simulcast as per RFC8853 MAY be supported by both the Media Servers and WHIP clients through negotiation in the SDP offer/answer. </ins> If the client supports simulcast and wants to enable it for publishing, it MUST negotiate the support in the SDP offer according

simulcast offer MUST create an answer according to the procedures RFC8853 section 5.3.2. <ins> It is possible for both Media Servers and WHIP clients to support Scalable Video Coding (SVC).  However, as there is no universal negotiation mechanism in SDP for SVC, the encoder must consider the negotiated codec(s), intended usage, and SVC support in available decoders when configuring SVC. </ins> 4.7. In order to support future extensions to be defined for the WHIP
Change:
I'd like to propose removing the mention of a specific company/brand in the abstract as well as some clarification around the language used to describe the protocol and why it is important/different from "other protocols".

Discussion:
Abstract <del> While WebRTC has been very successful in a wide range of scenarios, </del> <ins> While WebRTC has been very sucessful in a wide range of scenarios, </ins> its adoption in the broadcasting/streaming industry is lagging behind.  Currently there is no standard protocol (like SIP or RTSP) <del> designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it. These protocols are much older than webrtc and lack by default some important security and resilience features provided by webrtc with minimal delay. The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node, introducing delay and degrading media quality.  This transcoding step is always present in traditional streaming to support e.g.  ABR, and comes at no cost.  However webrtc implements client-side ABR, also called Network-Aware Encoding by e.g.  Huavision, by means of simulcast and SVC codecs, which otherwise alleviate the need for server-side transcoding.  Content protection and Privacy Enhancement can be achieved with End-to-End Encryption, which preclude any server-side media processing. </del> <ins> 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 end-to-end transport of media is implicit. </ins> This document proposes a simple HTTP based protocol that will allow <del> WebRTC endpoints to ingest content into streaming services and/or CDNs to fill this gap and facilitate deployment. </del> <ins> WebRTC based ingest of content into streaming servics and/or CDNs. </ins> 1.
Change:
While this is not ambiguous, it might be read as "MAY NOT". I suggest rewording as "Support for trickle ICE by WHIP resources is OPTIONAL".
NAME wdyt? is it ok to merge it and will this solve your concerns?
Yes, that's much better.

Discussion:
sending a HTTP PATCH request to the WHIP resource URL with a body containing a SDP fragment with MIME type "application/trickle-ice- sdpfrag" as specified in RFC8840 with the new ICE candidate or ICE <del> ufrag/pwd for ICE restarts.  A WHIP resource MAY not support trickle ICE (i.e.  ICE lite media servers) or ICE restart, in that case, it MUST return a 405 Method Not Allowed response for any HTTP PATCH request. </del> <ins> ufrag/pwd for ICE restarts. Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource. If Trickle ICE or ICE restarts are not supported by the WHIP resource, it MUST return a 405 Method Not Allowed response for any HTTP PATCH request. </ins> As the HTTP PATCH request sent by a WHIP client may be received out of order by the WHIP resource, the WHIP resource MUST generate a
Change:
So it's a MUST or a SHOULD?
NAME wdyt? is it ok to merge it and will it solve your concerns?
I'm sorry, but I still don't know what that says. Does it say that the client MUST NOT use If-Match on the DELETE, or does it say that the server MUST ignore an If-Match on the DELETE? I suggest making it clear to whom the requirement applies.
should be applicable only to clients, is it better now?
NAME ping?
I think this is still ambiguous due to the MUST in the first part. I suggest removing the first part:
what about now?
NAME ping?
merging this, we can modify it after the WGLC
Yeah, it's okay now.

Discussion:
contain an If-Match header with the latest known entity-tag as per RFC7232 section 3.1.  When the PATCH request is received by the WHIP resource, it MUST compare the entity-tag value requested with the <del> current entinty-tag of the resource as per RFC7232 section 3.1 and </del> <ins> current entity-tag of the resource as per RFC7232 section 3.1 and </ins> return a 412 Precondition Failed response if they do not match. <del> Entity-tag validation MUST only be used for HTTP requests requiring to match a known ICE session and SHOULD NOT be used otherwise, for example in the HTTP DELETE request to terminate the session. </del> <ins> WHIP clients SHOULD NOT use entity-tag validation when matching a specific ICE session is not required, such as for example when initiating a DELETE request in order to terminate a session. </ins> A WHIP resource receiving a PATCH request with new ICE candidates, but which does not perform an ICE restart, MUST return a 204 No
Change:
Authtentication, bearear, proposse, detailled, endpoings, adption, traditionnal.
Thank you very much!

Discussion:
Abstract While WebRTC has been very sucessful in a wide range of scenarios, <del> its adption in the broadcasting/streaming industry is lagging behind. Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it. </del> <ins> its adoption in the broadcasting/streaming industry is lagging behind.  Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it. </ins> These protocols are much older than webrtc and lack by default some important security and resilience features provided by webrtc with

The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node, introducing delay and degrading media quality.  This transcoding step <del> is always present in traditionnal streaming to support e.g.  ABR, and </del> <ins> is always present in traditional streaming to support e.g.  ABR, and </ins> comes at no cost.  However webrtc implements client-side ABR, also called Network-Aware Encoding by e.g.  Huavision, by means of simulcast and SVC codecs, which otherwise alleviate the need for

side media processing. This document proposes a simple HTTP based protocol that will allow <del> WebRTC endpoings to ingest content into streaming servics and/or CDNs </del> <ins> WebRTC endpoints to ingest content into streaming servics and/or CDNs </ins> to fill this gap and facilitate deployment. 1.

In the specific case of ingest into a platform, some assumption can be made about the server-side which simplifies the webrtc compliance <del> burden, as detailled in webrtc-gateway document. </del> <ins> burden, as detailed in webrtc-gateway document. </ins> https://tools.ietf.org/html/draft-ietf-rtcweb-gateways-02 <del> This document proposse a simple protocol for supporting WebRTC as </del> <ins> This document proposes a simple protocol for supporting WebRTC as </ins> ingest method which is: - Easy to implement, - As easy to use as current RTMP URI.  - Fully compliant with Webrtc and RTCWEB specs.  - <del> Allow for both ingest in traditionnal media platforms for extention </del> <ins> Allow for both ingest in traditional media platforms for extention </ins> and ingest in webrtc end-to-end platform for lowest possible latency. - Lowers the requirements on both hardware encoders and broadcasting services to support webrtc.  - Usable both in web browsers and in

4.4. <del> Authtentication and authorization is supported by the Authorization HTTP header with a bearear token as per RFC6750. </del> <ins> Authentication and authorization is supported by the Authorization HTTP header with a bearer token as per RFC6750. </ins> 4.5.
Change:
fix for
Unsure if trickle ICE is mandatory for webrtc or not, but it is optional for the APP point of view: as per rfc8829, 3.5.2. ICE Candidate Trickling: However I think it would not harm to point it out in Section 4.2
PR available here: URL
Is it legal for a server to support Trickle ICE but not ICE Restarts? If that's the case, then the use of 405 is somewhat misleading, since the PATCH method is allowed, just not for ICE Restarts.
I think you are correct, if patch request is not supported the server must return a 405 response, if only ice restarts are not supported it should return a 501 Not Implemented.
Does WebRTC mandate support of ICE restart and trickle ICE? If so, should the WHIP optional support be mentioned in Section 4.2 (WebRTC Constraints)?

Discussion:
used for ICE restarts, it will contain a new ICE ufrag/pwd pair. Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource. <del> If Trickle ICE or ICE restarts are not supported by the WHIP </del> <ins> If both Trickle ICE or ICE restarts are not supported by the WHIP </ins> resource, it MUST return a 405 Method Not Allowed response for any <del> HTTP PATCH request. </del> <ins> HTTP PATCH request.  If the WHIP resource supports either Trickle ICE or ICE restarts, but not both, it MUST return a 501 Not Implemented for the HTTP PATCH requests that are not supported. </ins> As the HTTP PATCH request sent by a WHIP client may be received out- of-order by the WHIP resource, the WHIP resource MUST generate a
Change:
Until now, I've been working under the assumption that WHIP is limited to two tracks (audio+video) belonging to a single stream. However, I'm now realising that there's nothing in the draft that says this is the case. Please clarify which of the following is correct: the client MUST offer at most one audio and one video track (possibly simulcast/SVC) belonging to a single stream; the server MUST return an error if there are more than two tracks; the client MAY offer more than two tracks; how to handle this case is out of scope for WHIP, but the server MAY return an error if there are more than two tracks and the client MUST retry with just two tracks; the client MAY offer multiple tracks in multiple streams, and the server MUST accept the multiple streams. My preference is for (1) or (2), but I can live with (3).
I had doubts regarding this, as I foresee that we will want to support multi tracks/streams in the near future (for multilanguage support for example) I would propose something like. I don't want to add the retry client logic to the client, as I think most of the times it would be better to inform the end user about the error and explicitly asking form confirmation before doing any change in the stream/track. Note that this could happen today if the server supports audio only and the whip client is sending audio and video. I think that it is better to fail than just force retrying automatically with audio only.

Discussion:
SHOULD include the "rtcp-mux-only" attribute in each bundled "m=" sections. <ins> While this version of the specification only supports a single audio and video track, in order to ensure forward compatibility, if the number of audio and or video tracks or number streams is not supported by the WHIP Endpoint, it MUST reject the HTTP POST request with a 406 Not Acceptable error code. Furthermore, the WHIP Endpoint SHOULD NOT reject individual "m=" sections as per RFC8829 section 5.3.1 in case there is any error processing the "m=" section, but reject the HTTP POST request with a 406 Not Acceptable error code to prevent having partially successful WHIP sessions. </ins> When a WHIP client sends an SDP offer, it SHOULD insert an SDP "setup" attribute with an "actpass" attribute value, as defined in RFC8842.  However, if the WHIP client only implements the DTLS client
Change:
As per discussion during IETF WISH meeting
thank you for the PR Adam! One further question, I think we should consistently use the return code and reason phrase styling across the document. what would be best? 200 OK 200 "OK" 200 (OK)

Discussion:
used for ICE restarts, it will contain a new ICE ufrag/pwd pair. Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource. <del> If both Trickle ICE or ICE restarts are not supported by the WHIP resource, it MUST return a 405 Method Not Allowed response for any HTTP PATCH request.  If the WHIP resource supports either Trickle ICE or ICE restarts, but not both, it MUST return a 501 Not Implemented for the HTTP PATCH requests that are not supported. </del> <ins> If the WHIP resource supports either Trickle ICE or ICE restarts, but not both, it MUST return a 405 (Not Implemented) for the HTTP PATCH requests that are not supported.  If the server does not support the PATCH method for any purpose, it returns a 501 (Not Implemented), as described in RFC7231 section 6.6.2. </ins> As the HTTP PATCH request sent by a WHIP client may be received out- of-order by the WHIP resource, the WHIP resource MUST generate a