Change:
If you find them useful, here are some spelling fixes. The ' PATH ' spelling is confusing, I think it should be ' PATCH ' Also the draft URL points to and older draft. I have been very inspired by WHIP, thank you for giving it to the community.

Discussion:
Abstract <del> While WebRTC has been very sucessful in a wide range of scenarios, </del> <ins> While WebRTC has been very successful in a wide range of scenarios, </ins> its adoption in the broadcasting/streaming industry is lagging behind.  Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media into a streaming service using WebRTC

The media codecs used for ingestion in older protocols tend to be limited and not negotiated.  WebRTC includes support for negotiation of codecs, potentially alleviating transcoding on the ingest node <del> (wich can introduce delay and degrade media quality).  Server side </del> <ins> (which can introduce delay and degrade media quality).  Server side </ins> transcoding that has traditionally been done to present multiple renditions in Adaptive Bit Rate Streaming (ABR) implementations can be replaced with simulcasting and SVC codecs that are well supported

media is implicit. This document proposes a simple HTTP based protocol that will allow <del> WebRTC based ingest of content into streaming servics and/or CDNs. </del> <ins> WebRTC based ingest of content into streaming services and/or CDNs. </ins> 1.

MUST return a 405 Method Not Allowed response for any HTTP PATCH request. <del> A WHIP resource receving a PATH request with new ICE candidates, but which does not perform an ICE restart, MUST return a 204 No content response without body. </del> <ins> A WHIP resource receiving a PATCH request with new ICE candidates, but which does not perform an ICE restart, MUST return a 204 No content response without body. </ins> If the HTTP PATCH request results in an ICE restart, the WHIP resource SHALL return a 200 OK with an "application/trickle-ice- sdpfrag" body containing the new ICE username fragment and password <del> and, optionaly, the new set of ICE candidates for the media server. </del> <ins> and, optionally, the new set of ICE candidates for the media server. </ins> As the HTTP PATCH request sent by a WHIP client may be received out of order by the WHIP resource, the WHIP resource SHOULD keep track of

HTTP POST request to the WHIP endpoint url. Each ICE server will be returned on a Link header with a "rel" <del> attribribute value of "ice-server" where the Link target URI is the ICE server URL and the credentials are encoded in the Link target </del> <ins> attribute value of "ice-server" where the Link target URI is the ICE server URL and the credentials are encoded in the Link target </ins> attributes as follows: username: If the Link header represents a TURN server, and <del> creadential-type is "password", then this attribute specifies the </del> <ins> credential-type is "password", then this attribute specifies the </ins> username to use with that TURN server. <del> credential: If credential-type attribute is misson or has a </del> <ins> credential: If credential-type attribute is missing or has a </ins> "password" value, the credential attribute represents a long-term authentication password, as described in RFC8489, Section 10.2.

WHIP endpoints and resources MAY require the HTTP request to be authenticated using an HTTP Authorization header with a Bearer token <del> as specified in RFC6750 section 2.1.  WHIP clients MUST implemenent </del> <ins> as specified in RFC6750 section 2.1.  WHIP clients MUST implement </ins> this authentication and authorization mechanism and send the HTTP Authorization header in all HTTP request sent to either the WHIP endpoint or resource. The nature, syntax and semantics of the bearer token as well as how to distribute it to the client is outside the scope of this document. <del> Some examples ot the kind of tokens that could be used are, but are </del> <ins> Some examples of the kind of tokens that could be used are, but are </ins> not limited to, JWT tokens as per RFC6750 and RFC8725 or a shared secret stored on a database.  The tokens are typically made available to the end user alongside the WHIP endpoint url and configured on the WHIP clients. WHIP endpoints and resources COULD perform the authentication and <del> authorization by encoding an authentication token withing the urls for the WHIP endpoints or resources instead.  In case the WHIP client is not configured to use a bearer token the HTTP Authorization header </del> <ins> authorization by encoding an authentication token within the urls for the WHIP endpoints or resources instead.  In case the WHIP client is not configured to use a bearer token the HTTP Authorization header </ins> must not be sent in any request. 4.6.

If the client supports simulcast and wants to enable it for publishing, it MUST negotiate the support in the SDP offer according to the procedures in RFC8853 section 5.3.  A server accepting a <del> simulcast offer MUST create an answer accoding to the procedures </del> <ins> simulcast offer MUST create an answer according to the procedures </ins> RFC8853 section 5.3.2. 4.7.