Re: [rtcweb] RTP usage: requirement levels

Bernard Aboba <bernard_aboba@hotmail.com> Mon, 16 July 2012 22:14 UTC

Message-ID: <BLU169-W123C346AD7917D9B55DB9FE93D40@phx.gbl>
Content-Type: multipart/alternative; boundary="_8871a758-4a76-42ba-8a01-57e44fc61794_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: martin.thomson@gmail.com, rtcweb@ietf.org
Date: Mon, 16 Jul 2012 15:15:21 -0700
Importance: Normal
In-Reply-To: <CABkgnnXWeAKNwUv70Uusujz0k11iA7a7g7ZHME99Vbq3RKQj5Q@mail.gmail.com>
References: <CABkgnnXWeAKNwUv70Uusujz0k11iA7a7g7ZHME99Vbq3RKQj5Q@mail.gmail.com>
MIME-Version: 1.0
Subject: Re: [rtcweb] RTP usage: requirement levels
Precedence: list

Good questions.  Some comments below. 

> Date: Mon, 16 Jul 2012 11:38:59 -0700
> From: martin.thomson@gmail.com
> To: rtcweb@ietf.org
> Subject: [rtcweb] RTP usage: requirement levels
> 
> The RTP usage draft current uses MUST, SHOULD, MAY to indicate two
> levels of compliance.  This is not a particularly good division for
> this sort of draft.
> 
> Firstly, it's unclear what meaningful distinction there is between
> SHOULD and MAY.  Then there is the distinction between MUST implement
> and MUST use.
> 
> The following classifications are more relevant to this sort of draft.
> 
> mandatory to USE
>  - all implementations MUST always use this feature
>  - there is no reason to signal support for the feature

[BA] Overall, I think we need a cleaner understanding of the meaning of the term "signal" in this document. 

The RTP usage document does not update any SDP standards, so if an SDP RFC describes how to do something, that still applies to SDP transmitted on the wire. 

On the other hand, if we are talking about whether an JSEP API implementation has to handle SDP that omits a mandatory to use feature (e.g., offering RTP/AVP with no key management functionality), I'd say "not a requirement, but an appropriate error message is still needed". 

>  - there is no reason to provide a means to disable it

[BA] If this is referring to the API, I would agree.  If we are referring to SDP, I'd say that the usual rules apply.  An endpoint (which after all could be legacy communicating via a gateway) can send a valid SDP answer that might not result in a session being established.  Being able to clearly indicate why the session could not be established is better than an undiagnosable failure. 

>  - no API requirements need to be derived for features that are mandatory to use
> 
> mandatory to IMPLEMENT
>  - all implementations MUST include support for the feature
>  - implementations MUST provide a means to enable and disable the
> feature (API requirement)
>  - there is no API requirement for indicating support of the feature

[BA]  Even if something is "mandatory to implement" there could still be a need to for the feature to be included in an SDP blob output by createOffer(), no?  Or to have a constraint relating to the feature?

> mandatory to DISABLE
>  - implementations MAY include support for the feature
>  - implementations MUST provide a means to signal support for the
> feature (API requirement)
>  - implementations that support the feature MUST provide a means to
> enable and disable the feature (optional API requirement)

[rtcweb] RTP usage: requirement levels Martin Thomson
Re: [rtcweb] RTP usage: requirement levels Bernard Aboba
Re: [rtcweb] RTP usage: requirement levels Martin Thomson
Re: [rtcweb] RTP usage: requirement levels Colin Perkins
Re: [rtcweb] RTP usage: requirement levels Martin Thomson
Re: [rtcweb] RTP usage: requirement levels Colin Perkins