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