Original text:
4.6. <del> Packaging of media describes how encapsulation of media to carry the raw media will work.  There are at a high level two approaches to this: </del>  Within the protocol itself, where the protocol defines the <del> carrying for each media encoding the ancillary data required for decoding the media. A common encapsulation format such as ISOBMFF which defines a generic method for all media and handles ancillary decode information. </del>  The working group must agree on which approach should be taken to the packaging of media, taking into consideration the various technical <del> trade offs that each provide.  If the working group decides on a common encapsulation format, the mechanisms within the protocol SHOULD allow for new encapsulation formats to be used. </del>  4.7.

Reviewer comments:
NAME - I am looking at , and wondering if I understand our point in our draft. Is it accurate to describe what WARP-04 is doing now, as ? If I understand the point, it's that we have to rev the specification, and implementations, in order to add a new package (because implementations that only support Container Format 0x0 for fMP4 don't know what to do with Container Format 0x1), so the distinction we are making seems (to me) to be about whether the protocol specification uses a generic method to tell a receiver how to decode media, rather than whether the protocol specification describes methods itself. Please let me know what you think, because I'm pretty sure I know what I want to say, unless I'm confused.
Starting thesis: The specification should support CMAF, in addition to CMAF, support non-contained {"RAW Elementary bitstream") media, and have agility to accommodate future container formats
A bunch of good comments get made in room but from requirement point of view, I think we need to have the ability to use something that has less overhead than CMAF particularly for audio. I don't see the need to use multiple types of containers in the same session and have them synchronized.
This issue was discussed at the MOQ interim meeting on 2023-01-31 - notes from that meeting are , and included here by reference. Anyone working on a PR for this issue should take a look at the discussion notes.
Hi, NAME would you be able to do a PR for this issue? This isn't my area of clue.
On today's authors' call, we think the starting point is now have agility to accommodate a variety of container formats support CMAF, support media formats that are not processed by relays (and relay-related MOQ capabilities) This document should also describe the requirements for additional container formats.
NAME - do you think what's in the document now (which isn't quite this ^^^^) is sufficient for an adoption call, or should we do a quick PR just retitling and rearranging the subsections?
We want agility, and we'll say that as a requirement, but we don't care what a MTI packaging would be (CMAF, fMP4, don't care), and we can defer to the protocol specification(s) (ex. WARP) to state those details, because those specifications will need to handle that anyway. It is likely that we need to handle codecs the same way (agility is the requirement, but we don't care about that, and the protocol specifications will need to handle that anyway).
What the document says now:

Revised text:
4.6.  <ins> Packaging of media describes how raw media will be encapsulated. There are at a high level two approaches to this: </ins> Within the protocol itself, where the protocol defines the  <ins> ancillary data required to decode each media type the protocol supports. A common encapsulation format such as ISOBMFF ISOBMFF which defines a generic method for all media and handles ancillary decode information. </ins> The working group must agree on which approach should be taken to the packaging of media, taking into consideration the various technical  <ins> trade offs that each approach provides. If the working group decides to describe media encapsulation as part of the MOQ protocol, this will require a new version of the MOQ protocol in order to signal the receiver that a new media encapsulation format may be present. If the working group decides to use a common encapsulation format, the mechanisms within the protocol SHOULD allow for new encapsulation formats to be used.  Without encapsulation agility, adding or changing the way media is encapsulated will also require a new version of the MOQ protocol, to signal the receiver that a new media encapsulation format may be present. MOQ protocol specifications will provide details on the supported media encapsulation(s). </ins> 4.7.