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

[Sean Turner <[e-mail]>]

Just wanted to check that these PRs are good to go?

spt

> On May 12, 2022, at 06:09, Sergio Garcia Murillo <[e-mail]> wrote:
> 
> 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
> 
> -- 
> Wish mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/wish