Draft: draft-ietf-wish-whip

Commentary: 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 .
While WebRTC has been very sucessful in a wide range of scenarios,
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
and so content providers still rely heavily on protocols like RTMP
for it.
While WebRTC has been very successful in a wide range of scenarios,
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
and so content providers still rely heavily on protocols like RTMP
for it.
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
(wich can introduce delay and degrade media quality).  Server side
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
by WebRTC clients.  In addition, WebRTC clients can adjust client-
side encoding parameters based on RTCP feedback to maximize encoding
quality.
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
(which can introduce delay and degrade media quality).  Server side
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
by WebRTC clients.  In addition, WebRTC clients can adjust client-
side encoding parameters based on RTCP feedback to maximize encoding
quality.
This document proposes a simple HTTP based protocol that will allow
WebRTC based ingest of content into streaming servics and/or CDNs.
This document proposes a simple HTTP based protocol that will allow
WebRTC based ingest of content into streaming services and/or CDNs.
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.
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
and, optionaly, the new set of ICE candidates for the media server.
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.
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
and, optionally, the new set of ICE candidates for the media server.
username: If the Link header represents a TURN server, and
creadential-type is "password", then this attribute specifies the
username to use with that TURN server.
credential: If credential-type attribute is misson or has a
"password" value, the credential attribute represents a long-term
authentication password, as described in RFC8489, Section 10.2.
username: If the Link header represents a TURN server, and
credential-type is "password", then this attribute specifies the
username to use with that TURN server.
credential: If credential-type attribute is missing or has a
"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
as specified in RFC6750 section 2.1.  WHIP clients MUST implemenent
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.
Some examples ot 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.  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
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
must not be sent in any request.
WHIP endpoints and resources MAY require the HTTP request to be
authenticated using an HTTP Authorization header with a Bearer token
as specified in RFC6750 section 2.1.  WHIP clients MUST implement
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.
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.  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
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
must not be sent in any request.
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
simulcast offer MUST create an answer accoding to the procedures
RFC8853 section 5.3.2.
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
simulcast offer MUST create an answer according to the procedures
RFC8853 section 5.3.2.