Hi Sergio, Thank you for addressing these questions. We updated the files per your response.
As of now, the open questions are #D, E, F, and G from our email sent 2025-02-07 (all relating to IANA updates). Please let us know if you have any questions as you review those. — FILES (please refresh) — Updated XML file: https://www.rfc-editor.org/authors/rfc9725.xml Updated output files: https://www.rfc-editor.org/authors/rfc9725.txt https://www.rfc-editor.org/authors/rfc9725.pdf https://www.rfc-editor.org/authors/rfc9725.html Diff files showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9725-auth48diff.html https://www.rfc-editor.org/authors/rfc9725-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9725-diff.html https://www.rfc-editor.org/authors/rfc9725-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9725-alt-diff.html (shows changes where text is moved or deleted) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9725 Thank you, RFC Editor/rv > On Feb 11, 2025, at 3:26 AM, Sergio Garcia Murillo > <sergio.garcia.muri...@gmail.com> wrote: > > > Hi Rebecca, thank you very much for the updates. > > I am answering the non-IANA changes here as I would need more time to digest > them. Will do in a following email. > > Best regards > Sergio > On Fri, Feb 7, 2025 at 8:38 PM Rebecca VanRheenen > <rvanrhee...@staff.rfc-editor.org> wrote: > Hi Sergio, > > Thank you for your reply. We have updated the document accordingly and have a > few followup questions. Note that we discussed D) and E) below with IANA > (copied on this email). The list of updated files is below the followup > questions. > > > Followup questions: > > A) >> > 5) <!-- [rfced] What does "such as ICE operations or termination" refer to? >> > >> > Original: >> > The WHIP >> > client can send requests to the WHIP session using this URL to >> > modify the session, such as ICE operations or termination. >> > --> >> >> ICE operations are described in 4.3 section, the termination refers to the >> session termination, maybe it is a good idea to include it on the sentence >> for clarity. > > Would it be helpful to update this text in one of the following ways for > clarity? > > Perhaps: > The WHIP client can send requests to modify the session (such as ICE > operations > or session termination) to the WHIP session using this URL. > > Or: > To modify the session (such as ICE operations > or session termination), the WHIP client can send requests to the WHIP > session using this URL. > > > Ok to that > > B) >> > 12) <!-- [rfced] May we update "being OPTIONAL otherwise" at the end of >> > this >> > sentence as follows to improve clarity? >> > >> > Original: >> > Consequently, as those HTTP PATCH requests may be received >> > out-of-order by the WHIP session, if WHIP session supports ICE >> > restarts, it MUST generate a unique strong entity-tag identifying the >> > ICE session as per Section 8.8.3 of [RFC9110], being OPTIONAL >> > otherwise. >> > >> > Perhaps: >> > Consequently, those HTTP PATCH requests may be received >> > out of order by the WHIP session. Thus, if WHIP session supports ICE >> > restarts, it MUST generate a unique strong entity-tag identifying the >> > ICE session as per Section 8.8.3 of [RFC9110]; >> > if the WHIP session does not support ICE restarts, this is OPTIONAL. >> > --> >> >> I don't think I agree with the change, what is optional is the support of >> the ICE restarts, how about: >> >> Consequently, those HTTP PATCH requests may be received >> out of order by the WHIP session. Thus, if WHIP session OPTIONALLY >> supports ICE >> restarts, it MUST generate a unique strong entity-tag identifying the >> ICE session as per Section 8.8.3 of [RFC9110]. > > Thank you for clarifying what is optional. Would one of the following updates > work? > > Perhaps: > Consequently, those HTTP PATCH requests may be received > out of order by the WHIP session. Thus, if the WHIP session supports ICE > restarts, it MUST generate a unique strong entity-tag identifying the > ICE session as per Section 8.8.3 of [RFC9110]. Support of ICE restarts > is OPTIONAL. > > Or: > Consequently, those HTTP PATCH requests may be received > out of order by the WHIP session. Thus, if the WHIP session supports ICE > restarts (which is OPTIONAL), it MUST generate a unique strong > entity-tag identifying the > ICE session as per Section 8.8.3 of [RFC9110]. > > > First one would be fine: > Consequently, those HTTP PATCH requests may be received > out of order by the WHIP session. Thus, if the WHIP session supports ICE > restarts, it MUST generate a unique strong entity-tag identifying the > ICE session as per Section 8.8.3 of [RFC9110]. Support of ICE restarts > is OPTIONAL. > > C) >>> > 16) <!-- [rfced] We have a few questions about the sentence below. >>> > >>> > a) The first part of the sentence includes "The WHIP endpoint SHOULD NOT >>> > reject". Should "but reject" in the second part of the sentence be >>> > updated to >>> > "but SHOULD reject" (i.e., include SHOULD)? >>> >>> I agree to adding "SHOULD", but maybe we should change the "but" to an >>> "instead"? >>> > >>> > b) Is a word missing in the phrase 'in case there is any error processing >>> > the >>> > "m=" section'? >>> >> I think it is fine, what do you find confusing? > > Should there perhaps be a preposition (e.g., “of” or “in") after “error > processing”? If the current is correct, we will leave as is. > > Current: > The WHIP endpoint SHOULD NOT reject individual "m=" sections as per > Section 5.3.1 of [RFC9429] in case there is any error processing the > "m=" section; > > Perhaps: > The WHIP endpoint SHOULD NOT reject individual "m=" sections as per > Section 5.3.1 of [RFC9429] in case there is any error processing of the > "m=" section; > > I am not native english speaker but "there is any error processing of the > "m=" section; " looks weird to me, how about: > > The WHIP endpoint SHOULD NOT reject individual "m=" sections, as specified > in > Section 5.3.1 of [RFC9429], if an error occurs when processing the "m=" > section. > > > H) >> > c.) Figures 2-5 in this document are too wide for the text output. Please >> > review and let us know how we should update. Note that RFC 8792 may be a >> > helpful resource for this. >> > --> >> >> Seems that the way of performing line wrapping in both SDP and HTTP is just >> truncating the line and adding an whitespace indentation on the continuation >> line below: >> >> so >> a=fingerprint:sha-256 >> F7:EB:F3:3E:AC:D2:EA:A7:C1:EC:79:D9:B3:8A:35:DA:70:86:4F:46:D9:2D:CC:D0:BC:81:9F:67:EF:34:2E:BD >> a=candidate:1 1 UDP 2130706431 198.51.100.1 39132 typ host >> >> would become >> a=fingerprint:sha-256 F7:EB:F3:3E:AC:D2:EA:A7:C1:EC:79:D9:B3: >> 8A:35:DA:70:86:4F:46:D9:2D:CC:D0:BC:81:9F:67:EF:34:2E:BD >> a=candidate:1 1 UDP 2130706431 198.51.100.1 39132 typ host > > We updated Figures 2-5 as you suggest (wrap long lines and indent the > continued line). Please review to ensure we did this correctly. These changes > are best viewed in the rfcdiff files. > > That's perfect, thanks > > I) Finally, we see both of the following phrases in the document. Are both > correct? > > username and password fragments > username fragment and password > > > The correct terms according to rfc8445 should be "username fragment and > password", so we need to change the "username and password fragments". > > > — FILES (please refresh) — > > Updated XML file: > https://www.rfc-editor.org/authors/rfc9725.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9725.txt > https://www.rfc-editor.org/authors/rfc9725.pdf > https://www.rfc-editor.org/authors/rfc9725.html > > Diff files showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9725-auth48diff.html > https://www.rfc-editor.org/authors/rfc9725-auth48rfcdiff.html (side by > side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9725-diff.html > https://www.rfc-editor.org/authors/rfc9725-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9725-alt-diff.html (shows changes > where text is moved or deleted) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9725 > > > Thank you, > > RFC Editor/rv > > > > > > >> On Feb 3, 2025, at 10:22 AM, Sergio Garcia Murillo >> <sergio.garcia.muri...@gmail.com> wrote: >> >> Hi, >> >> Thank you very much for the in depth review, I have provided my feedback on >> all the topics inline below. I think the only point I am not sure how to >> proceed is in the IANA charter proposed reorganization. >> >> Best regards >> Sergio >> >> On Fri, Jan 31, 2025 at 10:38 PM Sean Turner <s...@sn3rd.com> wrote: >> Adding in Sergio’s alternate email address. >> >> Cheers, >> spt >> >> > On Jan 31, 2025, at 3:29 PM, rfc-edi...@rfc-editor.org wrote: >> > >> > Authors, >> > >> > While reviewing this document during AUTH48, please resolve (as necessary) >> > the following questions, which are also in the XML file. >> > >> > >> > 1) <!-- [rfced] This is a question for Sergio. Your name appears as >> > follows in >> > the document header: >> > >> > Original: >> > S. Murillo >> > >> > Your name has appeared in various ways in the other RFCs that you have >> > authored (see below). Which form do you prefer? >> > >> > RFC 9605: >> > S. G. Murillo >> > >> > RFCs 9335 and 8079: >> > S. Garcia Murillo >> > S. Garcia Murillo >> >> I would prefer S. Garcia Murillo >> >> > >> > >> > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in >> > the title) for use on https://www.rfc-editor.org/search. --> >> webrtc, streaming, ingest >> > >> > 3) <!-- [rfced] How may we clarify the text that appears after the colon in >> > the sentence below? How does it connect to the rest of the sentence? >> > >> > Original: >> > Unfortunately, the lack of a standardized signaling mechanism in >> > WebRTC has been an obstacle to adoption as an ingestion protocol >> > within the broadcast/streaming industry, where a streamlined >> > production pipeline is taken for granted: plug in cables carrying raw >> > media to hardware encoders, then push the encoded media to any >> > streaming service or Content Delivery Network (CDN) ingest using an >> > ingestion protocol. >> > >> > Perhaps: >> > Unfortunately, the lack of a standardized signaling mechanism in >> > WebRTC has been an obstacle to its adoption as an ingestion protocol >> > within the broadcast and streaming industry, where a streamlined >> > production pipeline is taken for granted. For example, cables carrying >> > raw >> > media to hardware encoders are plugged in and then the encoded media is >> > pushed to any streaming service or Content Delivery Network (CDN) using >> > an >> > ingestion protocol. >> > --> >> >> That would work perfectly. >> >> > 4) <!-- [rfced] The list after Figure 1 is introduced as definitions of the >> > elements in Figure 1. However, "WHIP endpoint URL" and "WHIP session URL" >> > appear in the list but not in the figure. Are any updates needed? >> > >> > Original: >> > The elements in Figure 1 are described as follows: >> > --> >> The figure is ok, the URLs are attributes of the WHIP endpoint and WHIP >> session, which are needed for completing the flow. I think it is fine as it >> is. >> > >> > >> > 5) <!-- [rfced] What does "such as ICE operations or termination" refer to? >> > >> > Original: >> > The WHIP >> > client can send requests to the WHIP session using this URL to >> > modify the session, such as ICE operations or termination. >> > --> >> >> ICE operations are described in 4.3 section, the termination refers to the >> session termination, maybe it is a good idea to include it on the sentence >> for clarity. >> > >> > >> > 6) <!-- [rfced] If no objections, we will update these to be complete >> > sentences >> > as shown below. >> > >> > Original: >> > * WHIP client: Initiates the communication by sending an HTTP POST >> > with an SDP Offer to the WHIP endpoint. >> > >> > * WHIP endpoint: Responds with a "201 Created" message containing an >> > SDP answer. >> > >> > * WHIP client and media server: Establish an ICE and DTLS sessions >> > for NAT traversal and secure communication. >> > >> > * RTP/RTCP Flow: Real-time Transport Protocol and Real-time >> > Transport Control Protocol flows are established for media >> > transmission from the WHIP client to the media server, secured by >> > the SRTP profile. >> > >> > * WHIP client: Sends an HTTP DELETE to terminate the WHIP session. >> > >> > * WHIP session: Responds with a "200 OK" to confirm the session >> > termination. >> > >> > Perhaps: >> > * The WHIP client initiates the communication by sending an HTTP POST >> > with an SDP offer to the WHIP endpoint. >> > >> > * The WHIP endpoint responds with a "201 Created" message containing an >> > SDP answer. >> > >> > * The WHIP client and media server establish an ICE and DTLS sessions >> > for NAT traversal and secure communication. >> > >> > * RTP/RTCP flows are established for media >> > transmission from the WHIP client to the media server, secured by >> > the SRTP profile. >> > >> > * The WHIP client sends an HTTP DELETE to terminate the WHIP session. >> > >> > * The WHIP session responds with a "200 OK" to confirm the session >> > termination. >> > --> >> >> Fine for me, it looks better that way. >> > >> > >> > 7) <!-- [rfced] We were unable to find a "problem statement json object" >> > mentioned in RFC 9457. However, a "problem details JSON object" is >> > defined. Should the text below be updated accordingly? >> > >> > Original: >> > WHIP endpoints and resources could convey finer-grained error >> > information by a problem statement json object in the response message >> > body of >> > the failed request as per [RFC9457]. >> > >> > Perhaps: >> > WHIP endpoints and resources could convey more finely grained error >> > information with a problem details JSON object in the response message >> > body >> > of the failed request as per [RFC9457]. >> > --> >> >> My bad, should be problem details. >> >> > >> > >> > 8) <!-- [rfced] Are "perform" and "performing" the best word choice in >> > these >> > sentences? Or would "send/sending" or "make/making" be better? >> > >> > Original: >> > In order to set up an ingestion session, the WHIP client MUST >> > generate an SDP offer according to the JSEP rules for an initial >> > offer as in Section 5.2.1 of [RFC9429] and perform an HTTP POST >> > request as per Section 9.3.3 of [RFC9110] to the configured WHIP >> > endpoint URL. >> > ... >> > To explicitly terminate a WHIP session, the WHIP client MUST perform >> > an HTTP DELETE request to the WHIP session URL returned in the >> > Location header field of the initial HTTP POST. >> > ... >> > 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 >> > handle that request. >> > --> >> Yes, "send/sending" seems more appropriate. >> >> > >> > >> > 9) <!-- [rfced] Are the citations for RFC 8445 correct in the following >> > sentences? We ask because "ICE" does not appear in RFC 8445. Was the >> > intent to cite RFC 8445 (titled "Interactive Connectivity Establishment >> > (ICE): A Protocol for Network Address Translator (NAT) Traversal")? >> > >> > Original: >> > ICE [RFC8845] is a protocol addressing the complexities of NAT >> > traversal, commonly encountered in Internet communication. >> > ... >> > Depending on the Trickle ICE support on the WHIP client, the initial >> > offer by the WHIP client MAY be sent after the full ICE gathering is >> > complete with the full list of ICE candidates, or it MAY only contain >> > local candidates (or even an empty list of candidates) as per >> > [RFC8845]. >> > --> >> >> My bad again, should be 8445 and not 8845. >> > >> > >> > 10) <!-- [rfced] For ease of the reader, may we update this sentence as >> > follows >> > (i.e., split into two sentences and update "carrying" to ", which >> > carries")? >> > >> > Original: >> > The WHIP client MAY perform trickle ICE or ICE restarts by sending an >> > HTTP PATCH request as per [RFC5789] to the WHIP session URL, with a >> > body containing an SDP fragment with media type "application/trickle- >> > ice-sdpfrag" as specified in [RFC8840] carrying the relevant ICE >> > information. >> > >> > Perhaps: >> > The WHIP client MAY perform Trickle ICE or ICE restarts by sending an HTTP >> > PATCH request (as per [RFC5789]) to the WHIP session URL. This HTTP PATCH >> > request contains a body containing an SDP fragment with media type >> > "application/trickle-ice-sdpfrag" as specified in [RFC8840], which >> > carries the >> > relevant ICE information. >> > --> >> Should we use normative language instead of "contains" i.e. "MUST contain"? >> >> >> > >> > >> > 11) <!-- [rfced] Please review "If the HTTP PATCH to the WHIP session". >> > Should >> > this be updated as shown below? The previous sentence uses "WHIP session >> > URL". >> > >> > Original: >> > If the HTTP PATCH to the WHIP session has a content >> > type different than "application/trickle-ice-sdpfrag" or the SDP >> > fragment is malformed, the WHIP session MUST reject the HTTP PATCH >> > with an appropiate 4XX error response. >> > >> > Perhaps: >> > If the HTTP PATCH request sent to the WHIP session URL has a content >> > type different than "application/trickle-ice-sdpfrag" or the SDP >> > fragment is malformed, the WHIP session MUST reject the HTTP PATCH >> > with an appropriate 4xx error response. >> > --> >> >> I am fine with that too. >> > >> > >> > 12) <!-- [rfced] May we update "being OPTIONAL otherwise" at the end of >> > this >> > sentence as follows to improve clarity? >> > >> > Original: >> > Consequently, as those HTTP PATCH requests may be received >> > out-of-order by the WHIP session, if WHIP session supports ICE >> > restarts, it MUST generate a unique strong entity-tag identifying the >> > ICE session as per Section 8.8.3 of [RFC9110], being OPTIONAL >> > otherwise. >> > >> > Perhaps: >> > Consequently, those HTTP PATCH requests may be received >> > out of order by the WHIP session. Thus, if WHIP session supports ICE >> > restarts, it MUST generate a unique strong entity-tag identifying the >> > ICE session as per Section 8.8.3 of [RFC9110]; >> > if the WHIP session does not support ICE restarts, this is OPTIONAL. >> > --> >> >> I don't think I agree with the change, what is optional is the support of >> the ICE restarts, how about: >> >> Consequently, those HTTP PATCH requests may be received >> out of order by the WHIP session. Thus, if WHIP session OPTIONALLY >> supports ICE >> restarts, it MUST generate a unique strong entity-tag identifying the >> ICE session as per Section 8.8.3 of [RFC9110]. >> >> > >> > >> > 13) <!-- [rfced] If no objections, we will move the following sentences to >> > appear >> > before Figures 3 and 5, respectively, as the text introduces the figures. >> > >> > Original: >> > Figure 3 shows an example of the Trickle ICE procedure where the WHIP >> > client sends a PATCH request with updated ICE candidate information >> > and receives a successful response from the WHIP session. >> > ... >> > Figure 5 illustrates the Link headers included in a 201 Created >> > response, providing the ICE server URLs and associated credentials. >> > --> >> Fine for me >> > 14) <!-- [rfced] We have a few questions about this text: >> > >> > Original: >> > Figure 3 demonstrates a Trickle ICE restart procedure example. The >> > WHIP client sends a PATCH request containing updated ICE information, >> > including a new ufrag and password, along with newly gathered ICE >> > candidates. In response, the WHIP session provides ICE information >> > for the session after the ICE restart, including the updated ufrag >> > and password, as well as the previous ICE candidate. >> > >> > a) We updated "Figure 3" to "Figure 4". This text comes immediately after >> > Figure 4. If no objections, we will also move this text to appear before >> > Figure 4, as it introduces the figure. >> > >> > b) Is 'ufrag and password' correct, or should these be updated to >> > '"ice-pwd" >> > and "ice-ufrag"' (used earlier in the same section)? >> > --> >> >> "ice-pwd" and "ice-ufrag" are the sdp attributes, we may change them for the >> full name of the ICE properties: username fragment and password instead >> (without ") >> >> > >> > >> > 15) <!-- [rfced] Is "proving" the correct word choice here? Would >> > "providing" or >> > "that provides" be better? (Note that this sentence appears in both >> > Section 4.4.2 and 4.4.3.) >> > >> > Original: >> > The WHIP endpoint MAY also return a problem statement as >> > recommended in Section 4.1 proving further error details about the >> > failed request. >> > >> > Perhaps: >> > The WHIP endpoint MAY also return a problem statement that provides >> > further error details about the failed request, as >> > recommended in Section 4.1. >> > --> >> >> Sounds better. >> > >> > >> > 16) <!-- [rfced] We have a few questions about the sentence below. >> > >> > a) The first part of the sentence includes "The WHIP endpoint SHOULD NOT >> > reject". Should "but reject" in the second part of the sentence be updated >> > to >> > "but SHOULD reject" (i.e., include SHOULD)? >> >> I agree to adding "SHOULD", but maybe we should change the "but" to an >> "instead"? >> > >> > b) Is a word missing in the phrase 'in case there is any error processing >> > the >> > "m=" section'? >> >> I think it is fine, what do you find confusing? >> > >> > Original: >> > The WHIP endpoint SHOULD NOT reject individual "m=" sections as per >> > Section 5.3.1 of [RFC9429] in case there is any error processing the >> > "m=" section, but reject the HTTP POST request with an "422 >> > Unprocessable Content" or "400 Bad Request" error response to prevent >> > having partially successful ingest sessions which can be misleading >> > to end users. >> > >> > Perhaps: >> > The WHIP endpoint SHOULD NOT reject individual "m=" sections as per >> > Section 5.3.1 of [RFC9429] in case there is any error processing of the >> > "m=" section, but it SHOULD reject the HTTP POST request with a >> > "422 Unprocessable Content" or "400 Bad Request" error response to >> > prevent having partially successful ingest sessions, which can be >> > misleading to end users. >> > --> >> >> how about? >> >> The WHIP endpoint SHOULD NOT reject individual "m=" sections as per >> Section 5.3.1 of [RFC9429] in case there is any error processing of the >> "m=" section, instead it SHOULD reject the HTTP POST request with a >> "422 Unprocessable Content" or "400 Bad Request" error response to >> prevent having partially successful ingest sessions, which can be >> misleading to end users. >> > >> > >> > 17) <!-- [rfced] Most status codes mentioned in this document include a >> > description in addition to the number. Would you like to add that for 301 >> > and 302 below? If so, please confirm that the "301 Moved Permanently" and >> > "302 Found" are correct. >> > >> > Original: >> > In order to avoid POST requests to be redirected as GET >> > requests, status codes 301 and 302 MUST NOT be used and the preferred >> > method for performing load balancing is via the "307 Temporary >> > Redirect" response status code as described in Section 15.4.8 of >> > [RFC9110]. >> > >> > Perhaps: >> > In order to avoid POST requests being redirected as GET >> > requests, status codes "301 Moved Permanently" and "302 Found" MUST NOT >> > be used; >> > the preferred method for performing load balancing is via the "307 >> > Temporary >> > Redirect" response status code as described in Section 15.4.8 of >> > [RFC9110]. >> > --> >> > >> That would be perfect, thanks >> >> > >> > 18) <!-- [rfced] FYI - For clarity, we have updated the text starting with >> > "assumption..." as follows. Please review to ensure this does not change >> > your intended meaning. >> > >> > Original: >> > These requirements are based >> > on the assumption of the need to provide the data continuously, >> > within a very limited time window (no more delay than hundreds of >> > milliseconds end-to-end). >> > >> > Current: >> > These requirements are based >> > on the assumption that the data needs to be provided continuously, >> > within a very limited time window (a delay of no more than hundreds >> > of milliseconds end-to-end). >> > --> >> >> Seems better in the proposed text, I agree. >> > >> > >> > 19) <!-- [rfced] We were unable to find either "JWT tokens" or "JSON Web >> > Tokens" >> > mentioned explicitly in RFC 6750. Are any updates needed to the citation >> > in the text below? >> > >> > Original: >> > Some examples of the kind of tokens that could be used >> > are, but are not limited to, JWT tokens as per [RFC6750] and >> > [RFC8725] or a shared secret stored on a database. >> > --> >> >> we can drop rfc 6750 reference >> > >> > >> > 20) <!-- [rfced] FYI - We updated this sentence as follows to include the >> > name of >> > the IANA registry. >> > >> > Original: >> > Each protocol extension MUST register a unique "rel" attribute value >> > at IANA starting with the prefix: "urn:ietf:params:whip:ext" as >> > defined in Section 6.4. >> > >> > Updated: >> > Each protocol extension MUST register a unique "rel" attribute value >> > that starts with the prefix "urn:ietf:params:whip:ext" (as defined in >> > Section 6.4) in the "WebRTC-HTTP Ingestion Protocol (WHIP) Extension >> > URNs" registry (Section 6.3.2). >> > --> >> >> Ok >> > >> > >> > 21) <!-- [rfced] The first sentence below appears immediately before >> > Figure 6, and >> > the second sentence appears after. We suggest combining them and placing >> > before the figure. Which of the following suggestions do you prefer? >> > >> > Original: >> > In this theoretical case, the "201 Created" response to the HTTP POST >> > request would look like: >> > ... >> > Figure 6 shows an example of a WHIP protocol extension supported by >> > the WHIP session, as indicated in the Link header of the 201 Created >> > response. >> > >> > Perhaps: >> > In this theoretical case, the "201 Created" response to the HTTP POST >> > request >> > would look like the following (i.e., a WHIP protocol extension supported >> > by >> > the WHIP session, as indicated in the Link header of the "201 Created" >> > response). >> > >> > Or: >> > Figure 6 shows the "201 Created" response to the HTTP POST request in >> > this >> > theoretical case (i.e., the WHIP protocol extension supported by >> > the WHIP session, as indicated in the Link header of the "201 Created" >> > response). >> > --> >> >> I like the second text better >> >> > >> > >> > 22) <!-- [rfced] FYI - We updated "HTTP POST" (singular) here to be "HTTP >> > POST >> > requests" (plural). Let us know any concerns. >> > >> > Original: >> > It would be possible >> > for an attacker in possession of authentication credentials valid >> > for ingesting a WHIP stream to make multiple HTTP POST to the >> > WHIP endpoint. >> > >> > Current: >> > It would be possible >> > for an attacker in possession of authentication credentials valid >> > for ingesting a WHIP stream to make multiple HTTP POST requests to the >> > WHIP endpoint. >> > --> >> ok >> > >> > 23) <!-- [rfced] What does "it" refers to in this sentence? If "it" refers >> > to >> > "servers", we will update to "they"? >> > >> > Original: >> > If the connection rate is high >> > enough, this could lead to resource exhaustion on the servers >> > handling the requests and it will not be able to process >> > legitimate incoming ingests. >> > >> > Perhaps: >> > If the connection rate is high >> > enough, this could lead to resource exhaustion on the servers >> > handling the requests, and they will not be able to process >> > legitimate incoming ingests. >> > --> >> Yes, it should be "they" >> > >> > >> > 24) <!-- [rfced] How may we update the phrases below for consistency? >> > Perhaps as >> > "location of WHIP sessions" as shown below? >> > >> > WHIP session locations (plural "locations") >> > WHIP sessions location (plural "sessions") >> > WHIP sessions location URL >> > >> > Original: >> > * Insecure direct object references (IDOR) on the WHIP session >> > locations: If the URLs returned by the WHIP endpoint for the WHIP >> > sessions location are easy to guess, it would be possible for an >> > attacker to send multiple HTTP DELETE requests and terminate all >> > the WHIP sessions currently running. >> > ... >> > The security >> > considerations for Universally Unique IDentifier (UUID) [RFC9562], >> > Section 8 are applicable for generating the WHIP sessions location >> > URL. >> > >> > Perhaps: >> > * Insecure direct object references (IDOR) for the location of WHIP >> > sessions: If the URLs returned by the WHIP endpoint for the location >> > of WHIP >> > sessions are easy to guess, it would be possible for an >> > attacker to send multiple HTTP DELETE requests and terminate all >> > the WHIP sessions currently running. >> > ... >> > The security >> > considerations for Universally Unique IDentifiers (UUIDs) in Section >> > 8 of [RFC9562] >> > are applicable for generating the URL for the location of WHIP >> > sessions. >> > --> >> >> The text was written before we defined the "WHIP session URL" so we can use >> that instead: >> >> * Insecure direct object references (IDOR) for WHIP sessions URL: >> If the URLs returned by the WHIP endpoint for the location of WHIP >> sessions are easy to guess, it would be possible for an >> attacker to send multiple HTTP DELETE requests and terminate all >> the WHIP sessions currently running. >> ... >> The security >> considerations for Universally Unique IDentifiers (UUIDs) in Section 8 >> of [RFC9562] >> are applicable for generating the WHIP session URLs . >> > >> > >> > 25) <!-- [rfced] We have included some specific questions about the IANA >> > text in >> > the document. In addition to responding to those questions, please >> > review all of the IANA-related updates carefully and let us know if any >> > changes are needed. >> > --> >> > >> > >> > 26) <!-- [rfced] For the questions below, we will request that IANA update >> > the >> > registries to match the edited document prior to publication. >> > >> > a) Section 6.1: FYI - We made a minor edit (lowercased "Agent") in the >> > Description field of the "Link Relation Types" registry. >> > >> > Link to registry: https://www.iana.org/assignments/link-relations >> > >> > Original ("Agent"): >> > Description: Conveys the STUN and TURN servers that can be used by an >> > ICE Agent to establish a connection with a peer. >> > >> > Current ("agent"): >> > Description: Conveys the STUN and TURN servers that can be used by >> > an ICE agent to establish a connection with a peer. >> > >> Lower case should be the best option, yes >> >> >> > >> > b) Section 6.2: FYI - We capitalized the title of the registry >> > group (https://www.iana.org/assignments/whip). >> > >> > Original: >> > WebRTC-HTTP ingestion protocol (WHIP) >> > >> > Current: >> > WebRTC-HTTP Ingestion Protocol (WHIP) >> > >> >> OK >> >> > >> > c) Section 6.2, 6.3, and elsewhere: We also capitalized the titles of the >> > following registries (https://www.iana.org/assignments/whip). May we >> > further >> > update to use just the acronym WHIP rather than the expansion? WHIP is >> > already >> > expanded in the title of the registry group. >> > >> > Original: >> > WebRTC-HTTP ingestion protocol (WHIP) URNs >> > WebRTC-HTTP ingestion protocol (WHIP) Extension URNs >> > >> > Current (capitalized "Ingestion Protocol"): >> > WebRTC-HTTP Ingestion Protocol (WHIP) URNs >> > WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs >> > >> > Perhaps (use acronym): >> > WHIP URNs >> > WHIP Extension URNs >> >> I think that for the registry names it is better to contain the full >> expansion. >> > >> > d) Section 6.3.1: Similar to the above, may we shorten the Description >> > below >> > in the "WebRTC-HTTP ingestion protocol (WHIP) URNs" registry >> > (https://www.iana.org/assignments/whip)? >> > >> > Original: >> > Description: WebRTC-HTTP ingestion protocol (WHIP) extension URNs >> > >> > Perhaps: >> > Description: WHIP extension URNs >> > >> > >> >> Same >> >> > e) Section 6.3.1: After discussion with IANA, the "IANA Registry Reference" >> > field in the first registry at <https://www.iana.org/assignments/whip> >> > will be >> > updated as follows. >> > >> > Current: >> > [https://www.iana.org/assignments/whip] >> > >> > Should be: >> > See "WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs" on >> > [https://www.iana.org/assignments/whip] >> > >> > Or (depending on your response to question c above): >> > See "WHIP Extension URNs" on [https://www.iana.org/assignments/whip] >> > --> >> > >> >> Same >> > 27) <!-- [rfced] Other questions about IANA text >> > >> > a) Section 6: May we either remove this sentence or expand it to include >> > all >> > the IANA actions in the document? >> > >> > Original: >> > This specification adds a new link relation type and a registry for >> > URN sub-namespaces for WHIP protocol extensions. >> > >> > Perhaps: >> > Per this specification, IANA has added a new link relation type and >> > a new Registered Parameter Identifier for WHIP. IANA has also created >> > registries >> > to manage entries within the "urn:ietf:params:whip" and >> > "urn:ietf:params:whip:ext" namespaces. >> > >> >> good catch >> >> > >> > b) If no objections, we will reorganize the sections in the IANA >> > Considerations section as follows. The suggested organization corresponds >> > to >> > the IANA actions and groups information about each registry together in a >> > section. >> > >> > Original: >> > 6. IANA Considerations >> > 6.1. Link Relation Type: ice-server >> > 6.2. WebRTC-HTTP Ingestion Protocol (WHIP) registry group >> > 6.3. Registration of WHIP URN Sub-namespace and WHIP registries >> > 6.3.1. WebRTC-HTTP ingestion protocol (WHIP) URNs registry >> > 6.3.2. WebRTC-HTTP ingestion protocol (WHIP) extension URNs registry >> > 6.4. URN Sub-namespace for WHIP >> > 6.4.1. Specification Template >> > 6.5. Registering WHIP Protocol Extensions URNs >> > 6.5.1. Registration Procedure >> > 6.5.2. Guidance for Designated Experts >> > 6.5.3. WHIP Protocol Extension Registration Template >> > >> > Perhaps: >> > 6. IANA Considerations >> > 6.1. Link Relation Type: ice-server >> > 6.2. URN Sub-namespace for WHIP (urn:ietf:params:whip) >> > 6.3. WebRTC-HTTP Ingestion Protocol (WHIP) URNs Registry >> > 6.4. WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs Registry >> > 6.4.1. Registration Procedure >> > 6.4.2. Guidance for the Designated Expert >> > 6.4.3. Registration Template >> >> I am not sure about this change, could we double check with IANA if they are >> ok with the changes? >> > >> > c) Sections 6.3 and 6.4: It looks like Section 6.4.1 includes a template >> > from >> > Appendix A of RFC 3406. However, entries in the "IETF URN Sub-namespace for >> > Registered Protocol Parameter Identifiers" registry >> > (https://www.iana.org/assignments/params/) should use the template in >> > Section 4 >> > of RFC 3553. >> > >> > For examples, see: >> > Section 10.1.2 of RFC 9162 (urn:ietf:params:trans) >> > Section 9.3 of RFC 8620 (urn:ietf:params:jmap) >> > Section 9.6 of RFC 8555 (urn:ietf:params:acme) >> > >> > After discussion with IANA, we recommend 1) updating the text in Section >> > 6.3 >> > to include the template from RFC 3553 as follows and 2) removing Section >> > 6.4. >> > The text in Section 6.4 already appears in Section 4.9, and if needed, >> > information from the template in Section 6.4.1 can be folded into Section >> > 4.9. >> > >> > (Note that we would need you to provide text for the "Index value" field in >> > the suggested text below.) >> > >> > Original: >> > >> > 6.3. Registration of WHIP URN Sub-namespace and WHIP registries >> > >> > IANA is asked to add an entry to the "IETF URN Sub-namespace for >> > Registered Protocol Parameter Identifiers" registry and create a sub- >> > namespace for the Registered Parameter Identifier as per [RFC3553]: >> > "urn:ietf:params:whip". >> > >> > To manage this sub-namespace, IANA is asked to create the "WebRTC- >> > HTTP ingestion protocol (WHIP) URNs" and "WebRTC-HTTP ingestion >> > protocol (WHIP) extension URNs". >> > >> > >> > Perhaps (section numbers per suggested organization in previous question): >> > >> > 6.2. URN Sub-namespace for WHIP (urn:ietf:params:whip) >> > >> > IANA has added a new entry in the "IETF URN Sub-namespace for >> > Registered Protocol Parameter Identifiers" registry, following the >> > template in [RFC3553]: >> > >> > Registry name: whip >> > Specification: RFC 9725 >> > Repository: <https://www.iana.org/assignments/whip> >> > Index value: TBD >> > >> > To manage this sub-namespace, IANA has created two registries within >> > a new registry group called "WebRTC-HTTP Ingestion Protocol (WHIP)": >> > >> > * "WebRTC-HTTP Ingestion Protocol (WHIP) URNs" registry (Section 6.3) >> > * "WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs" registry >> > (Section 6.4) >> > >> > >> >> If IANA is ok with that, I am fine too. What is the index value? >> >> > d) If the template in Section 6.4 is removed per the question above, please >> > let us know how to update the following pointers to Section 6.4. Perhaps >> > these >> > should be updated to "Section 4.9"? >> > >> > Original: >> > Each protocol extension MUST register a unique "rel" attribute value >> > at IANA starting with the prefix: "urn:ietf:params:whip:ext" as >> > defined in Section 6.4. >> > ... >> > WHIP Protocol Extensions URNs have an "ext" type as defined in >> > Section 6.4. >> > >> Yes, 4.9 section would be correct >> >> >> > e) Section 6.3.1: Is this section number correct? Or should it be Section >> > 6.3.1? >> > >> > Original: >> > * Reference: this document (RFC TBD) Section Section 6.3.2 >> > >> > Perhaps: >> > Reference: RFC 9725, Section 6.3.2 >> > >> > >> I think the reference is correct, "Reference: RFC 9725, Section 6.3.2" >> should be good, right? >> >> >> > f) Section 6.4.1: Should "designated contact" here be updated to >> > "designated >> > expert"? >> > >> > Original: >> > * The designated contact shall be responsible for reviewing and >> > enforcing uniqueness. >> > >> >> Yes >> >> > >> > g) Section 6.5: FYI - We updated "Section 6.4" here be to "Section 6.3.2", >> > which is where the registry is defined. >> > >> > Original: >> > This section defines the process for registering new WHIP protocol >> > extensions URNs with IANA in the "WebRTC-HTTP ingestion protocol >> > (WHIP) extension URNs" registry (see Section 6.4). >> > >> > Updated: >> > This section defines the process for registering new WHIP protocol >> > extension URNs with IANA in the "WebRTC-HTTP Ingestion Protocol >> > (WHIP) Extension URNs" registry (see Section 6.3.2). >> > >> >> Ok, conditional to the section rewrite decision >> >> > >> > h) Section 6.5.2: We updated this text to be a bulleted list as shown >> > below. Please confirm that the placement of this sentence is correct: >> > "Specifications should be documented in an Internet-Draft." >> > >> > Original: >> > The Designated Expert (DE) is expected to ascertain the existence of >> > suitable documentation (a specification) as described in [RFC8126] >> > and to verify that the document is permanently and publicly >> > available. >> > >> > The DE is also expected to check the clarity of purpose and use of >> > the requested registration. >> > >> > Additionally, the DE must verify that any request for one of these >> > registrations has been made available for review and comment by >> > posting the request to the WebRTC Ingest Signaling over HTTPS (wish) >> > Working Group mailing list. >> > >> > Specifications should be documented in an Internet-Draft. Lastly, >> > the DE must ensure that any other request for a code point does not >> > conflict with work that is active in or already published by the >> > IETF. >> > >> > Perhaps: >> > The designated expert (DE) is expected to do the following: >> > >> > * Ascertain the existence of suitable documentation (a specification) >> > as described in [RFC8126] and to verify that the document is >> > permanently >> > and publicly available. Specifications should be documented in an >> > Internet-Draft. >> > >> > * Check the clarity of purpose and use of the requested registration. >> > >> > * Verify that any request for one of these registrations has been made >> > available for review and comment by posting the request to the WebRTC >> > Ingest >> > Signaling over HTTPS (wish) Working Group mailing list. >> > >> > * Ensure that any other request for a code point does not >> > conflict with work that is active in or already published by the >> > IETF. >> > >> OK >> >> >> > >> > i) Section 6.5.3: The template in this section and the fields on the IANA >> > registry do not exactly match, as shown below. Is it correct that the >> > template >> > should be updated to match the registry? >> > >> > Link to registy: https://www.iana.org/assignments/whip/ >> > >> > Template: >> > URN >> > Reference >> > Name >> > Description >> > Contact Information >> > >> > Registry: >> > URI >> > Description >> > Reference >> > IANA Registry Reference >> > Change Controller >> > >> yes , it should be changed >> >> > >> > j) This document includes a lot of detail about registering URNs in the >> > "WebRTC-HTTP ingestion Protocol (WHIP) Extension URNs" registry. Is any >> > additional information necessary for registering in the other WHIP >> > registry? >> > Both are "Specification Required". >> > --> >> >> The section should apply for both registries, yes >> >> > >> > 28) <!-- [rfced] This sentence cites [BCP9], but it seems that only RFC >> > 2026 >> > within BCP 9 contains information about the procedure for appeals. May we >> > update in one of the following ways to direct the reader to the RFC that >> > contains the applicable information? Note that the reference entry for >> > [BCP9] contains all RFCs that comprise BCP 9 (which has of now is eight). >> > >> > Original: >> > The normal appeals >> > procedure described in [BCP9] is to be followed. >> > >> > Perhaps: >> > The normal appeals >> > procedure described in RFC 2026 [BCP9] is to be followed. >> > >> > Or: >> > The normal appeals >> > procedure described in [RFC2026] is to be followed. >> > --> >> >> I think I got some feedback about using BCP and not RFCs directly, but I am >> fine if you think it is ok. >> > >> > >> > 29) <!-- [rfced] Please review the following questions and changes >> > regarding the >> > references used in this document. >> > >> > a.) This W3C recommendation has a new version dated October 2024. Would you >> > like to cite the latest version? If so, please confirm that the text in >> > this >> > document citing Section 4.2.1 of the W3C recommendation is still correct. >> > >> > Original: >> > [W3C.REC-webrtc-20210126] >> > Jennings, C., Ed., Boström, H., Ed., and J. Bruaroey, Ed., >> > "WebRTC 1.0: Real-Time Communication Between Browsers", >> > W3C REC REC-webrtc-20210126, W3C REC-webrtc-20210126, 26 >> > January 2021, >> > <https://www.w3.org/TR/2021/REC-webrtc-20210126/>. >> > >> > Perhaps: >> > [W3C.REC-webrtc-20210126] >> > Jennings, C., Ed., Castelli, F., Ed., Boström, H., Ed., and >> > J. Bruaroey, Ed., >> > "WebRTC: Real-Time Communication in Browsers", >> > W3C Recommendation, 8 October 2024, >> > <https://www.w3.org/TR/2024/REC-webrtc-20241008/>. Latest >> > version available at: <https://www.w3.org/TR/webrtc/>. >> > >> > Here is where this recommendation is cited in the text of this document: >> > >> > Original: >> > NOTE: The naming of both the "rel" attribute value of "ice-server" >> > and the target attributes follows the one used on the W3C WebRTC >> > recommendation [W3C.REC-webrtc-20210126] RTCConfiguration dictionary >> > in section 4.2.1. >> > >> Updating the reference would be great, the text is still valid after the >> reference update. >> >> > >> > b.) FYI - We have updated the text below as follows and provided a >> > citation in >> > the reference section for this URL. Please review and let us know any >> > objections. >> > >> > Original: >> > For example, considering a potential extension of server-to-client >> > communication using server-sent events as specified in >> > https://html.spec.whatwg.org/multipage/server-sent- >> > events.html#server-sent-events, >> > >> > Current: >> > For example, consider a potential extension of server-to-client >> > communication using server-sent events as specified in Section 9.2 of >> > [HTML]. >> > ... >> > [HTML] WHATWG, "HTML", WHATWG Living Standard, >> > <https://html.spec.whatwg.org/>. Commit snapshot: >> > <https://html.spec.whatwg.org/commit- >> > snapshots/09db56ba9343c597340b2c7715f43ff9b10826f6/>. >> > --> >> >> That is perfect, thank you. >> > >> > >> > 30) <!-- [rfced] Please review the following questions regarding the >> > terminology >> > used in this document. >> > >> > a.) Quotation marks appear around some of these terms but not others. >> > Please >> > review and let us know if quotes should be added or removed from any of >> > these >> > instances for consistency within the document. >> > >> > Access-Control-Request-Headers HTTP header >> > "Accept-Post" header >> > >> > HTTP Authorization header field >> > "If-Match" header field >> > Retry-After header field >> > >> > Location header >> > Location header field >> > >> > Link header >> > "Link" header field >> > Link header field >> > >> > ETag header >> > ETag header field >> > ETag response header field >> > >> > entity-tag value >> > "password" value >> > "POST" value >> > "Link" value >> >> In RFC 9110 it seems that only the first appearance of the header name is >> between quotres and every other >> reference is without it. So I think we should remove the quotes on the terms >> above, except on the "password" one, >> which defines the string value of the attribute. >> >> > >> > >> > b.) Both "Link attribute" and "Link target attributes" appear in the >> > sentences >> > below. Are these the same thing? If so, Let us know if updates are needed >> > for >> > consistency. >> > >> > Original: >> > WHIP clients MUST ignore any Link attribute with an unknown "rel" >> > attribute value and WHIP sessions MUST NOT require the usage of any >> > extension. >> > ... >> > The credentials are encoded in the Link >> > target attributes as follows: >> > >> >> Link target attribute should be the preferred term, would be good to update >> all "Link attribute" for consistency. >> >> > >> > c.) We note a number of instances of "WHIP protocol". As the "P" in "WHIP" >> > already stands for "protocol", this is repetitive when expanded (i.e., >> > "WebRTC-HTTP Ingestion Protocol protocol". >> > >> > If no objections, we will update the following instances as shown below to >> > avoid repetition. We will also update to use the lowercase "extension". >> > >> > WHIP protocol > WHIP >> > WHIP protocol extension > WHIP extension >> > WHIP Protocol Extension URN > WHIP extension URN >> fine for me >> >> > >> > d.) We see both of the following forms in the document. Should these be >> > uniform? If so, please let us know which form is preferred. >> > >> > ingestion session >> > ingest session >> > --> >> >> I am not a native english speaker, so I am fine with choosing the one that >> seems best in english but I am more prone to use "ingest session" >> > >> > >> > 31) <!-- [rfced] FYI - We have updated the terms below as follows. Please >> > review >> > and let us know any objections. >> > >> > a.) We updated the occurrence of line names as follows to match the use in >> > RFCs 9429 and 8866. >> > >> > m-line > "m=" line >> > m-sections > "m=" sections >> > >> > >> That's great, thank you >> >> > b.) We updated "2XX" and "4XX" to "2xx" and "4xx", respectively, per usage >> > in >> > RFC 9110. >> > >> >> ok >> >> > c.) We updated the single quotes to double quotes below for consistency >> > with >> > the other attributes in this document. Please let us know any objections. >> > >> > Original: >> > 'ice-options' >> > 'ice-pacing' >> > 'ice-lite' >> > >> > Current: >> > "ice-options" >> > "ice-pacing" >> > "ice-lite" >> ok >> >> >> > >> > d.) In Section 4.6, we added quotation marks for "credential-type" and >> > "credential" as attribute names elsewhere in the document are enclosed in >> > quotation marks. >> >> ok >> > >> > >> > e.) We have added expansions for abbreviations upon first use >> > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >> > expansion in the document carefully to ensure correctness. >> > >> > JavaScript Session Establishment Protocol (JSEP) >> > Extensible Messaging and Presence Protocol (XMPP) >> > Real-Time Streaming Protocol (RTSP) >> > Session Traversal Utilities for NAT (STUN) >> > Traversal Using Relays around NAT (TURN) >> > JSON Web Tokens (JWTs) >> > Real Time Messaging Protocol (RTMP) >> > --> >> >> Seem ok >> > >> > >> > 32) <!-- [rfced] Questions about XML formatting >> > >> > a.) Please review whether any of the notes in this document should be in >> > the >> > <aside> element. It is defined as "a container for content that is >> > semantically less important or tangential to the content that surrounds it" >> > (https://authors.ietf.org/en/rfcxml-vocabulary#aside). >> > >> >> I have always edited the rfs using markdown and converting it with the ietf >> tools but I believe that the notes in the document don't qualify for the >> aside element. >> >> > >> > b.) We updated <artwork> to <sourcecode> for Figures 2-6. Please consider >> > whether the "type" attribute of any sourcecode element should be set. >> > >> > The current list of preferred values for "type" is available at >> > <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. >> > If the current list does not contain an applicable type, feel free to >> > suggest additions for consideration. >> > >> > Note that it is also acceptable to leave the "type" attribute not set. >> >> Same, I have always edited the markdown so do not have much insight about >> it. Maybe we could use the "http-message" type for the http example figures. >> > >> > >> > c.) Figures 2-5 in this document are too wide for the text output. Please >> > review and let us know how we should update. Note that RFC 8792 may be a >> > helpful resource for this. >> > --> >> >> Seems that the way of performing line wrapping in both SDP and HTTP is just >> truncating the line and adding an whitespace indentation on the continuation >> line below: >> >> so >> a=fingerprint:sha-256 >> F7:EB:F3:3E:AC:D2:EA:A7:C1:EC:79:D9:B3:8A:35:DA:70:86:4F:46:D9:2D:CC:D0:BC:81:9F:67:EF:34:2E:BD >> a=candidate:1 1 UDP 2130706431 198.51.100.1 39132 typ host >> >> would become >> a=fingerprint:sha-256 F7:EB:F3:3E:AC:D2:EA:A7:C1:EC:79:D9:B3: >> 8A:35:DA:70:86:4F:46:D9:2D:CC:D0:BC:81:9F:67:EF:34:2E:BD >> a=candidate:1 1 UDP 2130706431 198.51.100.1 39132 typ host >> >> > >> > >> > 33) <!-- [rfced] Please review the "Inclusive Language" portion of the >> > online >> > Style Guide >> > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> > and let us know if any changes are needed. Updates of this nature >> > typically >> > result in more precise language, which is helpful for readers. >> > >> > Note that our script did not flag any words in particular, but this should >> > still be reviewed as a best practice. >> > --> >> >> I have reviewed the document and don't find anything that should be changed >> > >> > >> > Thank you. >> > >> > RFC Editor/kf/rv >> > >> > >> > On Jan 31, 2025, at 12:24 PM, rfc-edi...@rfc-editor.org wrote: >> > >> > *****IMPORTANT***** >> > >> > Updated 2025/01/31 >> > >> > RFC Author(s): >> > -------------- >> > >> > Instructions for Completing AUTH48 >> > >> > Your document has now entered AUTH48. Once it has been reviewed and >> > approved by you and all coauthors, it will be published as an RFC. >> > If an author is no longer available, there are several remedies >> > available as listed in the FAQ (https://www.rfc-editor.org/faq/). >> > >> > You and you coauthors are responsible for engaging other parties >> > (e.g., Contributors or Working Group) as necessary before providing >> > your approval. >> > >> > Planning your review >> > --------------------- >> > >> > Please review the following aspects of your document: >> > >> > * RFC Editor questions >> > >> > Please review and resolve any questions raised by the RFC Editor >> > that have been included in the XML file as comments marked as >> > follows: >> > >> > <!-- [rfced] ... --> >> > >> > These questions will also be sent in a subsequent email. >> > >> > * Changes submitted by coauthors >> > >> > Please ensure that you review any changes submitted by your >> > coauthors. We assume that if you do not speak up that you >> > agree to changes submitted by your coauthors. >> > >> > * Content >> > >> > Please review the full content of the document, as this cannot >> > change once the RFC is published. Please pay particular attention to: >> > - IANA considerations updates (if applicable) >> > - contact information >> > - references >> > >> > * Copyright notices and legends >> > >> > Please review the copyright notice and legends as defined in >> > RFC 5378 and the Trust Legal Provisions >> > (TLP – https://trustee.ietf.org/license-info). >> > >> > * Semantic markup >> > >> > Please review the markup in the XML file to ensure that elements of >> > content are correctly tagged. For example, ensure that <sourcecode> >> > and <artwork> are set correctly. See details at >> > <https://authors.ietf.org/rfcxml-vocabulary>. >> > >> > * Formatted output >> > >> > Please review the PDF, HTML, and TXT files to ensure that the >> > formatted output, as generated from the markup in the XML file, is >> > reasonable. Please note that the TXT will have formatting >> > limitations compared to the PDF and HTML. >> > >> > >> > Submitting changes >> > ------------------ >> > >> > To submit changes, please reply to this email using ‘REPLY ALL’ as all >> > the parties CCed on this message need to see your changes. The parties >> > include: >> > >> > * your coauthors >> > >> > * rfc-edi...@rfc-editor.org (the RPC team) >> > >> > * other document participants, depending on the stream (e.g., >> > IETF Stream participants are your working group chairs, the >> > responsible ADs, and the document shepherd). >> > >> > * auth48archive@rfc-editor.org, which is a new archival mailing list >> > to preserve AUTH48 conversations; it is not an active discussion >> > list: >> > >> > * More info: >> > >> > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >> > >> > * The archive itself: >> > https://mailarchive.ietf.org/arch/browse/auth48archive/ >> > >> > * Note: If only absolutely necessary, you may temporarily opt out >> > of the archiving of messages (e.g., to discuss a sensitive matter). >> > If needed, please add a note at the top of the message that you >> > have dropped the address. When the discussion is concluded, >> > auth48archive@rfc-editor.org will be re-added to the CC list and >> > its addition will be noted at the top of the message. >> > >> > You may submit your changes in one of two ways: >> > >> > An update to the provided XML file >> > — OR — >> > An explicit list of changes in this format >> > >> > Section # (or indicate Global) >> > >> > OLD: >> > old text >> > >> > NEW: >> > new text >> > >> > You do not need to reply with both an updated XML file and an explicit >> > list of changes, as either form is sufficient. >> > >> > We will ask a stream manager to review and approve any changes that seem >> > beyond editorial in nature, e.g., addition of new text, deletion of text, >> > and technical changes. Information about stream managers can be found in >> > the FAQ. Editorial changes do not require approval from a stream manager. >> > >> > >> > Approving for publication >> > -------------------------- >> > >> > To approve your RFC for publication, please reply to this email stating >> > that you approve this RFC for publication. Please use ‘REPLY ALL’, >> > as all the parties CCed on this message need to see your approval. >> > >> > >> > Files >> > ----- >> > >> > The files are available here: >> > https://www.rfc-editor.org/authors/rfc9725.xml >> > https://www.rfc-editor.org/authors/rfc9725.html >> > https://www.rfc-editor.org/authors/rfc9725.pdf >> > https://www.rfc-editor.org/authors/rfc9725.txt >> > >> > Diff file of the text: >> > https://www.rfc-editor.org/authors/rfc9725-diff.html >> > https://www.rfc-editor.org/authors/rfc9725-rfcdiff.html (side by side) >> > >> > Alt-diff of the text (allows you to more easily view changes >> > where text has been deleted or moved): >> > https://www.rfc-editor.org/authors/rfc9725-alt-diff.html >> > >> > Diff of the XML: >> > https://www.rfc-editor.org/authors/rfc9725-xmldiff1.html >> > >> > >> > Tracking progress >> > ----------------- >> > >> > The details of the AUTH48 status of your document are here: >> > https://www.rfc-editor.org/auth48/rfc9725 >> > >> > Please let us know if you have any questions. >> > >> > Thank you for your cooperation, >> > >> > RFC Editor >> > >> > -------------------------------------- >> > RFC9725 (draft-ietf-wish-whip-16) >> > >> > Title : WebRTC-HTTP ingestion protocol (WHIP) >> > Author(s) : S. Murillo, A. Gouaillard >> > WG Chair(s) : Sean Turner, Nils Ohlmeier >> > >> > Area Director(s) : Zaheduzzaman Sarker, Francesca Palombini >> > >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
