The draft does not explain how caching of Track Extensions works

[vasilvv]

It does not specify if/when it should cache them, it does not specify for how long it's supposed to cache them (presumably for as long as any objects related to the track are cached?), and it doesn't really specify what happens if a new response has different headers.

[afrind]

Proposal:

1. Cache track extensions as long as you have at least one object for that track cached, since you need them to send FETCH_OK
2. For extensions you understand, I think it's extension specific what to do. For extensions you don't understand, see How does a caching relay handle different unknown extensions? #1380.

[afrind]

I think this is purely editorial since it's evident from the design that you need to cache track extensions as long as you can serve objects from cache. The "different" case will be resolved by the fix for #1380.