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

Ted's interpretation is correct - this text is intentionally reiterating
3264's point that it is permissible to respond with codecs that weren't
offered, as this has been a frequent misunderstanding.

One option to clarify this could be to replace the "MAY" with "is permitted
to".

On Tue, Oct 24, 2017 at 1:36 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>