Re: [Wish] Review of normative language in WHIP draft

[Sergio Garcia Murillo <[e-mail]>]

Hi Juliusz,

Thank you for your feedback! Answers inline below:



> # Section 4.1.
>
> > A WHIP resource MAY not support trickle ICE
>
> While this is not ambiguous, it might be read as "MAY NOT".  I suggest
> rewording as "Support for trickle ICE by WHIP resources is OPTIONAL".
>

How about this?
https://github.com/wish-wg/webrtc-http-ingest-protocol/pull/28


> > Entity-tag validation MUST only be used for HTTP requests requiring to
> > match a known ICE session and SHOULD NOT be used otherwise
>
> So it's a MUST or a SHOULD?
>

I think that the confusing word is "only"
https://github.com/wish-wg/webrtc-http-ingest-protocol/pull/29


>
> > In any case the session MUST be terminated if the ICE consent expires as
> > a consequence of the failed ICE restart.
>
> Is this an additional requirement, or is it a consequence of a requirement
> elsewhere?  It is my understanding that the session MUST be terminated if
> ICE consent expires or is revoked, whether due to a failed ICE restart or
> any other reason.  This sentence should therefore not use normative
> language, as a normative requirement should be stated exactly once.
>
> Unfortunately, I cannot find where in the document it says how to deal
> with ICE consent expiration.  Otherwise, I would suggest something like
>
>   As pointed out in paragraph 42 of Section 57, the session must be
>   terminated if the ICE constent expires, whether as a consequence of
>   a failed ICE restart or any other reason.
>

Done in

https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/689b02ff1a651b4cef37165da6294fb4558dd9b0

Note that in rfc7675 section 5.1:

   Consent expires after 30 seconds.  That is, if a valid STUN binding
   response has not been received from the remote peer's transport
   address in 30 seconds, the endpoint MUST cease transmission on that
   5-tuple.



> # Section 4.2
>
> > SDP bundle SHALL be used by both the WHIP client and the media
> > server. The SDP offer created by the WHIP client MUST include the
> > bundle-only attribute in all m-lines as per [RFC8843].
>
> I suggest a non-normative "must", since it is not an extra requirement (it
> is a direct consequence of the normative SHALL).
>
>
done
https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/aaf0e6b4b92c39c53e245b1bcdcf15d99b2855f3


> # Section 4.3
>
> > WHIP endpoints and media servers MAY not be colocated on the same server
> > so it is possible to load balance incoming requests to different media
> > servers.
>
> "MAY not" might be read as "MAY NOT".  I suggest non-normative "might not
> be colocated".
>
> done
https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/7053cbb4e7fade9c5cde76920d75e12960562b3c



> > WHIP clients SHALL support HTTP redirection via the 307 Temporary
> > Redirect response code
>
> Is 308 not allowed?  I think it should be allowed.  If it's not allowed,
> please add a statement that servers MUST NOT reply with 308.
>

I don't think 308 is a good response code for load balancing:

   The 308 (Permanent Redirect) status code indicates that the target
   resource has been assigned a new permanent URI and any future
   references to this resource ought to use one of the enclosed URIs.


The intention of this paragraph is to ensure that the server can ensure
that the clients would support 307 for load balancing. I don't think we
should ban the usage of 308 which may be used for other purposes (for
example if the whip server has been moved to a different domain) and we
want to give a chance for the client to solve it instead of failing.



> > In case of high load, the WHIP endpoints MAY return a 503 (Service
> > Unavailable) status code
> [...]
> > The WHIP endpoint MAY send a Retry-After
>
> I suggest non-normative language ("might").  I also suggest merging the
> two paragraphs.
>
> Done
https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/26f0c88fe230ddefb139d1a64944b9745d1ca027


> # Section 4.4
>
> > the WHIP endpoint MAY also include the ICE server configuration on the
> > responses to an authenticated OPTIONS request
>
> I think that if the server includes ICE configuration in replies to POST,
> then it MUST, or at least SHOULD, also include that information in replies
> to OPTIONS.
>

Given that issuing TURN credentials can generate overload as they have to
allocate resources or be rate limited I would prefer to avoid making this
mandatory or even recommended, but just optional.


> > It COULD be also possible to configure
>
> I don't think is be normative.  I suggest "It may be also possible".
>
>
Done
https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/90cfa2ccc2837c9c47c0a15061fc9a432acb35ee

# Section 4.5
>
> > WHIP endpoints and resources MAY require the HTTP request to be
> authenticated
>
> I don't think this is normative -- the normative bit is the MUST in the
> next sentence.
>

I think that the MAY is correct here indicating that authentication request
by the servers is OPTIONAL

> WHIP endpoints and resources COULD perform the authentication and
> authorization
>
> Again, I don't see how this implies a requirement for the implementation.
> (In fact, the purpose of this whole paragraph is not clear to me.)
>

Done
https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/c5c9703677cbb3d0ec04a5edf500de17ec74fb5a


> # Section 4.7
>
> > WHIP servers MUST NOT require the usage of any of the extensions.
>
> I might be in the minority here, but I can see quite legitimate reasons
> for a WHIP server to reject an offer if the client does not implement some
> extension to the protocol.  For example, a server might reject offers that
> don't come with some non-standard authorisation token (for example based
> on EAP-SIM).


The idea of WHIP is about interoperability. We want to ensure that anyone
that implements a WHIP client based on this specification will be able to
speak to any WHIP server regardless of the extensions we make to the
protocol, ensuring backward compatibility.

Best regards
Sergio