Re: [rtcweb] JSEP: codecs in answer: MUST vs. MAY

I read this slightly differently, see below.

On Tue, Oct 24, 2017 at 12:58 PM, Jonathan Lennox <jonathan@vidyo.com>
wrote:

> JSEP (section 5.3.1) seems to be inconsistent about how whether
> locally-supported codecs that weren’t listed in a remote offer MUST, or
> MAY, be included in an answer:
>
>    o  If codec preferences have been set for the associated transceiver,
>       media formats MUST be generated in the corresponding order,
>       regardless of what was offered, and MUST exclude any codecs not
>       present in the codec preferences.
>
>
This is what you do if codec preferences are set (keep the order, and don't
add new ones)

>
>    o  Otherwise, the media formats on the m= line MUST be generated in
>       the same order as those offered in the current remote description,
>       excluding any currently unsupported formats.  Any currently
>       available media formats that are not present in the current remote
>       description MUST be added after all existing formats.
>
>
This is what you do if codec preferences are not set (keep the order, add
any new ones to the end)

>    o  In either case, the media formats in the answer MUST include at
>       least one format that is present in the offer, but MAY include
>       formats that are locally supported but not present in the offer,
>       as mentioned in [RFC3264], Section 6.1 <https://tools.ietf.org/html/rfc3264#section-6.1>.  If no common format
>       exists, the m= section is rejected as described above.
>
>
>
In either case, if you don't have at least one codec that matches, you
reject the m= section (don't add any new ones).

I think the MAY there from RFC 3264 permits the behavior in the  "if not
codec preferences are set" behavior branch, but doesn't require it, which
is why there can be a branch like the one where codec preferences are set
and they are not sent.

> The first two paragraphs certainly seem to indicate that these codecs MUST
> be included in the answer; however, the third paragraph suddenly weakens
> this to a MAY.
>
> Is the intent of the third paragraph simply to restate RFC 3264’s loose
> requirements, whereas the first two are JSEP’s more binding ones?  If so, I
> think this should be stated more clearly, otherwise the required behavior
> is unclear.
>
> _

So I don't personally see an inconsistency in this, but if you have other
language, please suggest it.  We're already in IESG evaluation, but it
might be a friendly amendment by Adam or someone else.

regards,

Ted

> ______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>