How safe is to use the 120-126 extension ID range?

[lmiguelgato]

Based on version 5 of the IETF draft, when choosing extension ID, my take is that an application using Opus should not choose 0–2 or 127. It should also not use 3–119, unless it's intended for broader interoperability or standardization, in which case it requires to publish an IANA registration request.

Then 120–126 is the only defined range in the draft where we can choose IDs for private or prototype usage.

However, these are officially “experimental,” which could mean that:

1. They should not be relied on for long-term interoperability.
2. Two independent implementations using experimental IDs might collide unless coordinated.
3. A future RFC may redefine usage and require code changes.

If today an application uses, let's say ID=120 for a custom extension. I understand that other applications can be using the same ID for a different purpose. And that's fine, because they wouldn't collide with my application's scope.

Within the scope of my application and its user base, how safe is to stick to an ID from the experimental range without taking the risk that future Opus lib versions could repurpose it? Assuming a case in which we are not planning to publicly standardize our usage.

Another way to frame this question: Instead of "experimental", can they be declared as "private-use", and guaranteed to remain that way in later iterations?

[xnorpx]

@jmvalin

[jmvalin]

The reason we do not have a user-defined range of IDs is that extensions could have interactions with each other and we rely on the standardization process to define the exact behaviour. So your use of ID=120 for application-specific extension is not something we encourage, but we cannot stop you. The only guaranty about that ID is that it'll remain an experimental ID, but it's possible that future Opus extension development will use it. In any case, if things break, you get to keep the pieces.

[jmvalin]

In general I can see three cases that could apply to what you're doing:

1. Your extension would be useful to others. In that case, I would encourage you to submit it for standardization and get an IANA-registered ID
2. Your extension makes a good case that we made a mistake in not allowing application-specific extension IDs. In that case I would suggest arguing that ASAP in the mlcodec WG so that we can revise the decision before the draft becomes RFC (which should be soon).
3. Neither 1 nor 2 applies, in which case, maybe using an experimental ID isn't a good idea.

[lmiguelgato]

Thank you. I will submit a request to the mlcodec WG to review this aspect of the spec, and to consider reserving a small subset of extension IDs for private or application-specific use.

[silverbacknet]

Worth noting that no.2 on your list will still be the case. At best you can guard against that by adding an additional 1-3 byte start code as a best practice, to at least cut down on the likelihood of a collision, much as the spec requests a 1 byte identifier and 1 byte versioning to the experimental range.