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 --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 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. --> 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: --> 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. --> 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. --> 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]. --> 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. --> 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]. --> 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. --> 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. --> 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. --> 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. --> 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)? --> 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. --> 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)? b) Is a word missing in the phrase 'in case there is any error processing the "m=" section'? 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. --> 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]. --> 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). --> 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. --> 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). --> 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). --> 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. --> 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. --> 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. --> 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. 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) 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 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 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] --> 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. 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 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) 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. 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 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. 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). 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. 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 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". --> 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. --> 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. 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/>. --> 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 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: 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 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 --> 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 b.) We updated "2XX" and "4XX" to "2xx" and "4xx", respectively, per usage in RFC 9110. 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" 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. 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) --> 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). 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. 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. --> 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. --> 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
