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

[Juliusz Chroboczek <[e-mail]>]

> Juliusz, as I think it was you the one that commented on the issue, could you
> highlight an example one of what should be changed?

Always at your service :-)

# 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".

> 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?

> 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.

# 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).

# 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".

> 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.

> 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.

# 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.

> It COULD be also possible to configure

I don't think is be normative.  I suggest "It may be also possible".

# 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.

> 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.)

# 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).

-- Juliusz