Draft: draft-ietf-wish-whip

Commentary: As per 
 thank you new changes per your feedback 
 PATCH request may be received out of order , how do we handle that ? ICE candidate , ICE restart reversed order : ICE candidate with old ufrag should be discarded ICE restart , ICE candidate reversed order : Should ICE candidate trigger ICE restart anyway ? Agreed solution : use Etag for requests / responses
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.
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
the previous values of the ICE username fragment and client used by
the WHIP client.  If an HTTP PATCH request is received with a
previously used ICE username fragment and password by the client, the
WHIP endpoint SHALL NOT perform and ICE restart but reject the
request with a 409 Conflict response instead.
As the HTTP PATCH request sent by a WHIP client may be received out
of order by the WHIP resource, the WHIP resource MUST generate a
unique strong entity-tag identifying the ICE session as per RFC7232
section 2.3.  The initial value of the entity-tag identifying the
initial ICE session MUST be returned in an ETag header in the 201
response to the initial POST request to the WHIP endpoint and in the
200 OK of a PATCH request that triggers an ICE restart.
A WHIP client sending a PATCH request for performing trickle ICE MUST
contain an If-Match header with the latest known entity-tag as per
RFC7232 section 3.1.  When the PATCH request is received by the WHIP
resource, it MUST compare the entity-tag value requested with the
current entinty-tag of the resource as per RFC7232 section 3.1 and
return a 412 Precondition Failed response if they do not match.
Entity-tag validation MUST only be used for HTTP requests requiring
to match a known ICE session and SHOULD NOT be used otherwise, for
example in the HTTP DELETE request to terminate the session.
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 media server does not support
a candidate transport or is not able to resolve the connection
address it MUST accept the HTTP request with the 204 response and
silently discard the candidate.
A WHIP client sending a PATCH request for performing ICE restart MUST
contain an If-Match header with a field-value "*" as per RFC7232
section 3.1.
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
and the new entity-tag correspond to the new ICE session in an ETag
response header.
If the ICE request can not be performed by the WHIP resource it MUST
return an appropriate HTTP error code but MUST NOT terminate the
session immediately.  The WHIP client COULD try again to perform a
new ICE restart or terminate the session issuing a HTTP DELETE
request instead.  In any case the session MUST be terminated if the
ICE consent expires as a consequence of the failed ICE restart.
Given that in order to send new ICE candidates to the WHIP resource,
the WHIP client needs to know the entity-tag associated to the ICE
session, it MUST buffer any gathered candidates before the HTTP
response to the initial PUT request or the PATCH request with the new
entity-tag value is received.  Once the entity-tag value is known the
WHIP client SHOULD send a single aggregated HTTP PATCH request with
all the ICE candidates it has buffered so far.
credential-type: If the Link header represents represents a TURN
server, then this attribute specifies how the credential attribute
value should be used when that TURN server requests authorization.
The default value if the attribute is not present is "password".
credential-type: If the Link header represents a TURN server, then
this attribute specifies how the credential attribute value should
be used when that TURN server requests authorization.  The default
value if the attribute is not present is "password".
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.
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 requests sent to either the WHIP
endpoint or resource.
Each protocol extension MUST register an unique "rel" attribute
values at IANA starting with the prefix: "urn:ietf:params:whip:".
Each protocol extension MUST register a unique "rel" attribute values
at IANA starting with the prefix: "urn:ietf:params:whip:".