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

[Jonathan Lennox <[e-mail]>]

> On Oct 25, 2017, at 12:47 AM, Justin Uberti <[e-mail]> wrote:
> 
> 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.

Okay, good, that’s what I hoped; but this is mixing up normative text (MUST reject if no common codec) with informative, which is confusing.

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

I would go further than this, clearly distinguishing the normative text from the informative. Perhaps:

In either case, the media formats in the answer MUST include at least one format that is present in the offer.  If no common format exists, the m= section is rejected as described above.
(Note that in SDP offer/answer, an answer is permitted to include formats that are locally supported but not present in the offer, as mentioned in [RFC3264], Section 6.1.  As described in the preceding paragraphs, in JSEP including these formats is mandatory.)


> On Tue, Oct 24, 2017 at 1:36 PM, Ted Hardie <[e-mail] <mailto:[e-mail]>> wrote:
> I read this slightly differently, see below.
> 
> On Tue, Oct 24, 2017 at 12:58 PM, Jonathan Lennox <[e-mail] <mailto:[e-mail]>> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
> 
>