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 > --> > > > 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
