[Mlcodec] Re: Last call for Opus Extension

[Roman Shpount <[e-mail]>]

Hi Timothy,

After I reread this and thought about it a bit more I have a few technical
comments:

In the introduction, it would be helpful to add that existing decoders will
safely ignore all non-zero padding (already true per RFC6716), and that
extended decoders MUST behave identically to legacy decoders when
extensions are absent, ensuring backward compatibility.

Section 2  states that  "An encoder MUST NOT alter the way it encodes the
non-extension part of an Opus packet in such a way as to noticeably reduce
its quality when decoded with a non-extended decoder." What does
"noticeably" mean in this context? Should this reference RFC 6716 Section 6
instead?

In Section 2.1, the document provides the example of extension encoding.
Still, it would be helpful to state explicitly that "L is the least
significant bit of the extension ID byte, with the upper 7 bits encoding
the ID."

It would help to make the "ignore on overrun" rule more prominent and
centralized. I would suggest making a section stating that "Any extension
signaled with a length that would cause the decoder to read beyond the
bounds of the packet MUST be ignored," and then referencing this from the
RTE and Separator sections.

In section 2.2. ID 1: Separator
* It should probably be named "Frame Separator" for consistency
* Is it legal to have a separator with L=1 and the following byte 0? This
would be functionally equivalent to no separator.

In section 2.3. ID 2: Repeat These Extensions (RTE)
It would be easier to follow if some examples were added. Specifically,
examples of all corner cases, such as the final long extension with L=0
when followed by repeated short extensions or multiple RTEs per frame.

In section 3. IANA Considerations: a new registry is defined. It would be
helpful to provide the IANA registration template.

In section 3.2 Mapping to SDP Parameters
You are referencing  RFC5576 Section 6.3. This section refers to fmtp ssrc
parameters, not to media parameters in general. The meaning of media-level
parameters is typically defined according to the codec. Therefore, I
recommend not referencing RFC5576 and specifying the handling of these
parameters in this document by stating that "The media-level format
parameters described in this document MUST be explicitly specified and MUST
NOT be carried over blindly from another offer or answer." Furthermore,
"receiver MUST be capable of receiving any signal" should be more specific,
such as "receiver MUST be capable of decoding any unknown or non-negotiated
extensions, even if the negotiation fails."

In security considerations:
Should we include a language that malicious packets can be constructed with
extensions claiming excessive length, thereby introducing the risk of
buffer overflows? RFC 6716 already warns against malicious packets, but it
might be prudent to add additional language here.

Best regards,
_____________
Roman Shpount


On Fri, Aug 8, 2025 at 10:39 AM Roman Shpount <[e-mail]> wrote:

> Hi Timothy,
>
> These are the things I noticed:
> "A given extension ID MAY appear multiple times and the ordering of
> extension instances within each Opus frame is significant"
> should be
> "A given extension ID MAY appear multiple times. The ordering of extension
> instances within each Opus frame is significant"
>
> "A particular extension ID definition MAY place further restrictions on
> count and ordering of these extensions instances"
> should be
> "A particular extension ID definition MAY place further restrictions on
> the count and the ordering of these extension instances"
>
> "Reordering of extension instances between Opus frames caused by the
> repeat mechanism is not significant and an extended decoder MUST treat
> repeated extensions as equivalent to the same extensions coded individually"
> should be
> "Reordering of extension instances between Opus frames caused by the
> repeat mechanism is not significant, and an extended decoder MUST treat
> repeated extensions as equivalent to the same extensions coded individually"
>
> "In the case where the L flag is set, the extension ID byte (0x01) is
> simply skipped and extension decoding continues from the next byte."
> should be
> "In the case where the L flag is set, the extension ID byte (0x01) is
> simply skipped, and extension decoding continues from the next byte."
>
> "Only the extensions which follow the most recent RTE (if any) are
> repeated by a subsequent RTE."
> should be
> "Only the extensions that follow the most recent RTE (if any) are repeated
> by a subsequent RTE."
>
> "These extensions are to be defined in their own respective documents and
> the IDs are to be assigned by IANA."
> should be
> "These extensions are to be defined in their own respective documents, and
> the IDs are to be assigned by IANA. "
>
> "Due to potential for interaction between extensions"
> should be
> "Due to the potential interaction between extensions"
>
> This document defines a new registry "Opus Extension IDs" in a new "Opus"
> group, that allocates individual IDs to individual extensions to be defined
> in the future.
> should be
> This document defines a new registry, "Opus Extension IDs", in a new
> "Opus" group, that allocates individual IDs to individual extensions to be
> defined in the future.
>
> Best regards,
> _____________
> Roman Shpount
>
>
> On Fri, Aug 8, 2025 at 6:40 AM Timothy B. Terriberry <[e-mail]>
> wrote:
>
>> Roman Shpount wrote:
>> > This document appears to be well-written (apart from a few missing
>> > commas before the "and" in the compound sentences). I have no negative
>>
>> I found four. Let me know if I missed any.
>>
>