Code change:
3.1. <del> The catalog object MUST have a track ID of 0. </del> <ins> Per MoQTransport sect X.X, the catalog object MUST have a track name of "catalog". </ins> <del> Each catalog object MUST be independent of other catalog objects and MUST carry a unqiue group sequence number (see MoQTransport, Sect X.X).  The first catalog published MUST have a group sequence number of 0.  Every catalog object MUST have an object sequence number of 0 and there MUST be only one object per catalog group.  A catalog track object SHOULD be published only when the availability of tracks changes. </del> <ins> A catalog object MAY be independent of other catalog objects or it MAY represent a delta update of a prior catalog object.  The first catalog object published within a new group MUST be independent.  A catalog object SHOULD only be published only when the availability of tracks changes. </ins> <del> The format of the CATALOG object payload, as defined by MoQTransport Sect X.X, is as follows: </del> <ins> The format of the CATALOG object payload is as follows: </ins> Media format type: this MUST hold the value 0x001 (see IANA). <ins> This value MUST NOT be encrypted. </ins> Version: this MUST be the version of WMF to which the media packaging and catalog serialization conforms. <del> Track count: The number of tracks described by the catalog.  A catalog describing 0 tracks is a signal to the WMF client that the publishing session is complete. Each track is described by a track descriptor with the format: Track ID: Within WMF, track IDs are numeric integers.  Track IDs SHOULD start at 0 and SHOULD increment by 1 for each additional track.  Track IDs MUST never be reused.  If a track is published and then unpublished, it must be allocated a new track ID before it is re-published. Init payload: The init payload in a track descriptor MUST consist of a File Type Box (ftyp) followed by a Movie Box (moov).  This Movie Box (moov) consists of Movie Header Boxes (mvhd), Track Header Boxes (tkhd), Track Boxes (trak), followed by a final Movie Extends Box (mvex).  These boxes MUST NOT contain any samples and MUST have a duration of zero.  A Common Media Application Format Header CMAF meets all these requirements. </del> <ins> Parent object ID: 0 if this object represents an independent catalog or the parent object ID if this represents a delta update. Track change count: The number of track changes described by the catalog.  A catalog update describing 0 tracks, or deleting all existing tracks, SHALL be interpreted by the WMF client to mean that the publishing session is complete.  A WMF client SHOULD process all changes before making a subscription selection. Each track change is described by a track change descriptor with the format: Track name length: the length of track name field Track name: the UTF-8 encoded track name.  Within MoQTransport track names are strings.  Track names MUST never be reused.  If a track is published and then unpublished, it must be allocated a new track name before it is re-published.  A catalog MUST NOT reference itself i.e the the track name must not be "catalog". Operation: a binary flag. 1 if the track is being added and 0 if it is being deleted.  A publisher MUST NOT signal deletion of a track that has not been previously added. Change payload: depends upon the value of the operation flag.  If the operation is a 1 (add), then it SHALL hold an Initialization Header.  If the operation is 0 (delete), then it SHALL hold a Deletion Header. Init length: the length of the init payload Init payload: The init payload MUST consist of a File Type Box (ftyp) followed by a Movie Box (moov).  This Movie Box (moov) consists of Movie Header Boxes (mvhd), Track Header Boxes (tkhd), Track Boxes (trak), followed by a final Movie Extends Box (mvex). These boxes MUST NOT contain any samples and MUST have a duration of zero.  A Common Media Application Format Header CMAF meets all these requirements. Last group: holds the last MoQTransport Group sequence number published under that track name. Last object: holds the last MoQTransport Object sequence number published under that track name. </ins> 3.2.

Related discussion:
text: The current draft allows tracks within a catalog to be updated. This causes a few problems: What happens if a track is changed (ex. new profile)? When does this update occur? What happens when the catalog update is delayed? If the publisher changes the codec/profile in the middle of a track, the decoder will blow up. There's no way to know when the change will take place.
I don't see how we could easily support tracks being updated. At the very least we would need a group ID when the change occurs, but that won't work in the face of packet loss, because the catalog update could arrive after the starting group. I think the only way to fix this is to put the init information at the start of each group (ex. SPS/PPS) which is not desirable. I would prohibit it for now. At the very least, some text to say that the init payload MUST NOT change on subsequent updates. We can only add or remove tracks.
IMO we start with no catalog updates for interop. Then we can build an ADD and REMOVE track message to avoid retransmitting the entire catalog on each update.
NAME By 'update', I agree that we shouldn't allow their media characteristics (anything described in the init segment or the init itself) to change. But we should allow them to be added and deleted . Agree I think that having no catalog updates in v1 is unnecessarily restrictive and would lead to missed use-cases, rather than better interop. We also don't need to invent ADD and REMOVE track messages if we allow the CATALOG (and its updates) to define the availability of tracks. The whole purpose of the CATALOG track is to do exactly that. This point is up to MOQ base protocl however and we need to resolve it there. And "avoiding retransmitting the entire catalog on each update" can be addressed by either ignoring (because catalog updates are small to begin even with their init payloads), or by allowing delta updates on the catalog, which wouldn't be complex and I can mock that up if you'd like to see what it might look like?
Yeah, the ADD and REMOVE messages would be delta updates. I think we need some timing information about when a track starts and ends, although I'm not sure.