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
