jiebi/TextFlow huggingface dataset:
Original text:
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>  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>  A WHIP resource receiving a PATCH request with new ICE candidates, but which does not perform an ICE restart, MUST return a 204 No

Reviewer comments:
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.

Revised text:
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  <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.  <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
Original text:
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>  resource, it MUST return a 405 Method Not Allowed response for any <del> HTTP PATCH request. </del>  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

Reviewer comments:
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)?

Revised text:
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.  <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  <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
Original text:
SHOULD include the "rtcp-mux-only" attribute in each bundled "m=" sections.  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

Reviewer comments:
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.

Revised text:
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
Original text:
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>  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

Reviewer comments:
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)

Revised text:
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.  <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
Original text:
specifications which may use this mechanism to configure the usage of STUN/TURN servers. <del> There are some WebRTC implementations that do not support updating the STUN/TURN server configuration after the local offer has been created as specified in RFC8829 section 4.1.18.  In order to support these clients, the WHIP endpoint MAY also include the STUN/TURN server configuration on the responses to OPTIONS request sent to the WHIP endpoint URL before the POST request is sent. </del> NOTE: Depending on the ICE Agent implementation, the WHIP client may need to call the setConfiguration method before calling the setLocalDespcription method with the local SDP offer in order to avoid having to perform an ICE restart for applying the updated STUN/ TURN server configuration on the next ICE gathering phase.  The generation of the TURN server credentials may require performing a request to an external provider, which can both add latency to the OPTIONS request processing and increase the processing required to

Reviewer comments:
NAME could you take a look please?
The current text ignores the issue that (in the absence of OPTIONS) the offer must be sent before it is set as the local description, in order to avoid starting the ICE agent prematurely. I think we should consult an ICE specialist in order to understand what consequences that will have on connectivity.
There is already a note already covering that case. It is up to the WHIP client implementation to know which is its ICE implementation support regarding this case and choose to call setLocalDescription or not before updateConfiguration. The only case were a WHIP client is not tightly coupled with a ICE implementation is on browsers, and we already have checked that it works on all webrtc browsers.

Revised text:
specifications which may use this mechanism to configure the usage of STUN/TURN servers.  NOTE: Depending on the ICE Agent implementation, the WHIP client may need to call the setConfiguration method before calling the setLocalDespcription method with the local SDP offer in order to avoid having to perform an ICE restart for applying the updated STUN/ TURN server configuration on the next ICE gathering phase. <ins> There are some WebRTC implementations that do not support updating the STUN/TURN server configuration after the local offer has been created as specified in RFC8829 section 4.1.18.  In order to support these clients, the WHIP endpoint MAY also include the STUN/TURN server configuration on the responses to OPTIONS request sent to the WHIP endpoint URL before the POST request is sent.  However, this method is not NOT RECOMMENDED and if supported by the underlying WHIP Client's webrtc implementation, the WHIP Client SHOULD wait for the information to be returned by the WHIP Endpoint on the response of the HTTP POST request instead. </ins> The generation of the TURN server credentials may require performing a request to an external provider, which can both add latency to the OPTIONS request processing and increase the processing required to
Original text:
If the HTTP PATCH request results in an ICE restart, the WHIP resource SHALL return a "200 OK" with an "application/trickle-ice- sdpfrag" body containing the new ICE username fragment and password. <del> The response may optionally contain the new set of ICE candidates for the Media Server and the new entity-tag correspond to the new ICE session in an ETag response header field. </del>  If the ICE request cannot be satisfied by the WHIP resource, the resource MUST return an appropriate HTTP error code and MUST NOT

Reviewer comments:
NAME ping?
“The response may optionally contain the new set of ICE candidates for the Media Server and the new entity-tag correspond to the new ICE session in an ETag response header field.” Is this really meant to indicate that the new ICE candidates AND the new entity-tag are optional? I would have expected that after an ICE restart a new entity-tag is required.
The optionally only applies to the first part of, will reword it.

Revised text:
If the HTTP PATCH request results in an ICE restart, the WHIP resource SHALL return a "200 OK" with an "application/trickle-ice- sdpfrag" body containing the new ICE username fragment and password.  <ins> Also, the "200 OK" response for a sucesscull ICE restart MUST contain the new entity-tag corresponding to the new ICE session in an ETag response header field and MAY contain a new set of ICE candidates for the Media Server. </ins> If the ICE request cannot be satisfied by the WHIP resource, the resource MUST return an appropriate HTTP error code and MUST NOT
Original text:
Once the ICE/DTLS session is set up, the media will flow unidirectionally from the encoder/media producer (WHIP client) to the broadcasting ingestion endpoint (Media Server).  In order to reduce <del> complexity, no SDP renegotiation is supported, so no tracks or streams can be added or removed once the initial SDP offer/answer over HTTP is completed. </del>  4. SHOULD include the "rtcp-mux-only" attribute in each bundled "m=" sections as per RFC8858. <del> While this version of the specification only supports, at most, a single audio and video track in a single media stream. (therefore, all "m=" sections MUST contain an "msid" attribute with the same value as per [[!RFC8830]]), 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 response. </del>  Furthermore, the WHIP Endpoint SHOULD NOT reject individual "m=" sections as per RFC8829 section 5.3.1 in case there is any error

Reviewer comments:
Looks good.
thank you Bernard!
from NAME Section 2 I do not see a definition of “track”. I think this is important to clarify. Section 4.2 “ 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 response.”
updated the PR to add MediaStream/MediaStreamTrack references

Revised text:
Once the ICE/DTLS session is set up, the media will flow unidirectionally from the encoder/media producer (WHIP client) to the broadcasting ingestion endpoint (Media Server).  In order to reduce  <ins> complexity, no SDP renegotiation is supported, so no "m=" sections can be added once the initial SDP offer/answer over HTTP is completed. </ins> 4. SHOULD include the "rtcp-mux-only" attribute in each bundled "m=" sections as per RFC8858.  <ins> This version of the specification only supports, at most, a single audio and video MediaStreamTrack in a single MediaStream as defined in [[!RFC8830]] and therefore, all "m=" sections MUST contain an "msid" attribute with the same value.  However, it would be possible for future revisions of this spec to allow more than a single MediaStream or MediaStreamTrack of each media kind, so 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 response. </ins> Furthermore, the WHIP Endpoint SHOULD NOT reject individual "m=" sections as per RFC8829 section 5.3.1 in case there is any error