jiebi/TextFlow huggingface dataset:
Original text:
or catalog object.  A namespace declared in a track object or catalog object overwrites any inherited name space. <del> 3.2.9. </del>  A string defining the name of the track.  See section 2.3 of MoQTransport.  Within the catalog, track names MUST be unique per namespace. <del> 3.2.10. </del>  A string defining the type of payload encapsulation.  Allowed values are strings as defined in Table 2. Table 2: Allowed packaging values <del> 3.2.11. </del>  Each track description can specify an optional operation value that identifies the catalog producer's intent.  Track operation is a

Reviewer comments:
We need the following Add Catalog Seq Number and explain how it is related to Parent Seq Num Make parent seq num independent of MoQT object number
Proposal is to add two fields: Catalog sequence number (CSN)- a required integer starting at 0 and monotonically increasing with each successive catalog update. Parent sequence number (PSN) - an optional reference pointing at a prior (not necessarily previous) catalog sequence number. If the PSN is absent, then the catalog is an independent catalog. If it is present, then the catalog represents a delta update. Having a sequence number independent of the transport sequencing allows catalogs to be distributed over moq-transport, or http or another transport and still be interpreted correctly.

Revised text:
or catalog object.  A namespace declared in a track object or catalog object overwrites any inherited name space.  <ins> 3.2.10. </ins> A string defining the name of the track.  See section 2.3 of MoQTransport.  Within the catalog, track names MUST be unique per namespace.  <ins> 3.2.11. </ins> A string defining the type of payload encapsulation.  Allowed values are strings as defined in Table 2. Table 2: Allowed packaging values  <ins> 3.2.12. </ins> Each track description can specify an optional operation value that identifies the catalog producer's intent.  Track operation is a
Original text:
The default track operation is 'Add'.  This value does not need to be declared in the track object. <del> 3.2.12. </del>  A string defining a human-readable label for the track.  Examples might be "Overhead camera view" or "Deutscher Kommentar".  Note that the JSON spec requires UTF-8 support by decoders. <del> 3.2.13. </del>  An integer specifying a group of tracks which are designed to be rendered together.  Tracks with the same group number SHOULD be

Reviewer comments:
We need the following Add Catalog Seq Number and explain how it is related to Parent Seq Num Make parent seq num independent of MoQT object number
Proposal is to add two fields: Catalog sequence number (CSN)- a required integer starting at 0 and monotonically increasing with each successive catalog update. Parent sequence number (PSN) - an optional reference pointing at a prior (not necessarily previous) catalog sequence number. If the PSN is absent, then the catalog is an independent catalog. If it is present, then the catalog represents a delta update. Having a sequence number independent of the transport sequencing allows catalogs to be distributed over moq-transport, or http or another transport and still be interpreted correctly.

Revised text:
The default track operation is 'Add'.  This value does not need to be declared in the track object.  <ins> 3.2.13. </ins> A string defining a human-readable label for the track.  Examples might be "Overhead camera view" or "Deutscher Kommentar".  Note that the JSON spec requires UTF-8 support by decoders.  <ins> 3.2.14. </ins> An integer specifying a group of tracks which are designed to be rendered together.  Tracks with the same group number SHOULD be
Original text:
accompany one another.  A common example would be tying together audio and video tracks. <del> 3.2.14. </del>  An integer specifying a group of tracks which are alternate versions of one-another.  Alternate tracks represent the same media content,

Reviewer comments:
We need the following Add Catalog Seq Number and explain how it is related to Parent Seq Num Make parent seq num independent of MoQT object number
Proposal is to add two fields: Catalog sequence number (CSN)- a required integer starting at 0 and monotonically increasing with each successive catalog update. Parent sequence number (PSN) - an optional reference pointing at a prior (not necessarily previous) catalog sequence number. If the PSN is absent, then the catalog is an independent catalog. If it is present, then the catalog represents a delta update. Having a sequence number independent of the transport sequencing allows catalogs to be distributed over moq-transport, or http or another transport and still be interpreted correctly.

Revised text:
accompany one another.  A common example would be tying together audio and video tracks.  <ins> 3.2.15. </ins> An integer specifying a group of tracks which are alternate versions of one-another.  Alternate tracks represent the same media content,
Original text:
be a set video tracks of the same content offered in alternate bitrates. <del> 3.2.15. </del>  A string holding Base64 BASE64 encoded initialization data for the track. <del> 3.2.16. </del>  A string specifying the track name of another track which holds initialization data for the current track.  Initialization tracks

Reviewer comments:
We need the following Add Catalog Seq Number and explain how it is related to Parent Seq Num Make parent seq num independent of MoQT object number
Proposal is to add two fields: Catalog sequence number (CSN)- a required integer starting at 0 and monotonically increasing with each successive catalog update. Parent sequence number (PSN) - an optional reference pointing at a prior (not necessarily previous) catalog sequence number. If the PSN is absent, then the catalog is an independent catalog. If it is present, then the catalog represents a delta update. Having a sequence number independent of the transport sequencing allows catalogs to be distributed over moq-transport, or http or another transport and still be interpreted correctly.

Revised text:
be a set video tracks of the same content offered in alternate bitrates.  <ins> 3.2.16. </ins> A string holding Base64 BASE64 encoded initialization data for the track.  <ins> 3.2.17. </ins> A string specifying the track name of another track which holds initialization data for the current track.  Initialization tracks
Original text:
only via the initialization track field of the track which they initialize. <del> 3.2.17. </del>  An object holding a series of name/value pairs which a subscriber can use to select tracks for subscription.  If present, the selection

Reviewer comments:
We need the following Add Catalog Seq Number and explain how it is related to Parent Seq Num Make parent seq num independent of MoQT object number
Proposal is to add two fields: Catalog sequence number (CSN)- a required integer starting at 0 and monotonically increasing with each successive catalog update. Parent sequence number (PSN) - an optional reference pointing at a prior (not necessarily previous) catalog sequence number. If the PSN is absent, then the catalog is an independent catalog. If it is present, then the catalog represents a delta update. Having a sequence number independent of the transport sequencing allows catalogs to be distributed over moq-transport, or http or another transport and still be interpreted correctly.

Revised text:
only via the initialization track field of the track which they initialize.  <ins> 3.2.18. </ins> An object holding a series of name/value pairs which a subscriber can use to select tracks for subscription.  If present, the selection
Original text:
declaration of a selection parameter at the track level overrides the inherited root value. <del> 3.2.18. </del>  Certain tracks may depend on other tracks for decoding.  Dependencies holds an array of track names trackname on which the current track is

Reviewer comments:
We need the following Add Catalog Seq Number and explain how it is related to Parent Seq Num Make parent seq num independent of MoQT object number
Proposal is to add two fields: Catalog sequence number (CSN)- a required integer starting at 0 and monotonically increasing with each successive catalog update. Parent sequence number (PSN) - an optional reference pointing at a prior (not necessarily previous) catalog sequence number. If the PSN is absent, then the catalog is an independent catalog. If it is present, then the catalog represents a delta update. Having a sequence number independent of the transport sequencing allows catalogs to be distributed over moq-transport, or http or another transport and still be interpreted correctly.

Revised text:
declaration of a selection parameter at the track level overrides the inherited root value.  <ins> 3.2.19. </ins> Certain tracks may depend on other tracks for decoding.  Dependencies holds an array of track names trackname on which the current track is
Original text:
The following rules MUST be followed in processing delta updates: If a catalog is received without the parent sequence number field <del> parentsequencenumber defined, then it is an independent catalog and no delta update processing is required. If a catalog is received with a parent sequence number field present, then the content of the catalog MUST be parsed as if the catalog contents had been added to the contents received on the referenced moq-transport object.  Newer field definitions overwrite older field definitions. </del>  Track namespaces may not be changed across delta updates.

Reviewer comments:
We need the following Add Catalog Seq Number and explain how it is related to Parent Seq Num Make parent seq num independent of MoQT object number
Proposal is to add two fields: Catalog sequence number (CSN)- a required integer starting at 0 and monotonically increasing with each successive catalog update. Parent sequence number (PSN) - an optional reference pointing at a prior (not necessarily previous) catalog sequence number. If the PSN is absent, then the catalog is an independent catalog. If it is present, then the catalog represents a delta update. Having a sequence number independent of the transport sequencing allows catalogs to be distributed over moq-transport, or http or another transport and still be interpreted correctly.

Revised text:
The following rules MUST be followed in processing delta updates: If a catalog is received without the parent sequence number field  <ins> parentsequence defined, then it is an independent catalog and no delta update processing is required. If a catalog is received with the parent sequence number field present, then the contents of the catalog MUST be parsed as if the catalog contents had been added to the state represented by the catalog whose sequence number matches the parent sequence number. Newer field definitions overwrite older field definitions. </ins> Track namespaces may not be changed across delta updates.
Original text:
of the catalog may subscribe to the track. Delete: Indicates that media producer is no longer producing media <del> on the associated track. </del>  A catalog update in which all previously added tracks are deleted SHOULD be interpreted by a subscriber to indicate that the publisher

Reviewer comments:
There was a feedback from Victor on making track operation string enumeration to enhance readability. It feels like a fine suggestion

Revised text:
of the catalog may subscribe to the track. Delete: Indicates that media producer is no longer producing media  <ins> on the associated track.  Subscribers SHOULD terminate their subscriptions. </ins> A catalog update in which all previously added tracks are deleted SHOULD be interpreted by a subscriber to indicate that the publisher
Original text:
Table 3: Allowed track operations <del> The default track operation is 'Add'.  This value does not need to be </del>  declared in the track object. 3.2.13.

Reviewer comments:
There was a feedback from Victor on making track operation string enumeration to enhance readability. It feels like a fine suggestion

Revised text:
Table 3: Allowed track operations  <ins> The default track operation is 'add'.  This value does not need to be </ins> declared in the track object. 3.2.13.
Original text:
3.2.9. The name space under which the track name is defined.  See section <del> 2.3 of MoQTransport.  The track namespace is required to be specified for each track object.  If the track namespace is declared in the root of the JSON document, then its value is inherited by all tracks and catalogs and it does not need to be re-declared within each track or catalog object.  A namespace declared in a track object or catalog object overwrites any inherited name space. </del>  3.2.10.

Reviewer comments:
Consensus for merging at IETF meeting.
Per the discussion at URL, it would be useful that if the namespace were absent, that track names would inherit the namespace of the catalog track in which they were defined. This capability allows for relative naming, which aids in portability.
I know there has been lots of debate on this but it seems reasonable.

Revised text:
3.2.9. The name space under which the track name is defined.  See section  <ins> 2.3 of MoQTransport.  If the track namespace is declared in the root of the JSON document, then its value is inherited by all tracks and catalogs and it does not need to be re-declared within each track or catalog object.  A namespace declared in a track object or catalog object overwrites any inherited name space.  The track namespace is optional.  If it is not declared at the root or track level, then each track MUST inherit the namespace of the catalog track. </ins> 3.2.10.
Original text:
This example shows catalog for a media producer capable of sending 3 time-aligned video tracks for high definition, low definition and <del> medium definition video qualities, along with an audio track. </del>  3.4.3.

Reviewer comments:
Consensus for merging at IETF meeting.
Per the discussion at URL, it would be useful that if the namespace were absent, that track names would inherit the namespace of the catalog track in which they were defined. This capability allows for relative naming, which aids in portability.
I know there has been lots of debate on this but it seems reasonable.

Revised text:
This example shows catalog for a media producer capable of sending 3 time-aligned video tracks for high definition, low definition and  <ins> medium definition video qualities, along with an audio track.  In this example the namesapce is absent, which infers that each track must inherit the namespace of the catalog. </ins> 3.4.3.
Original text:
A number indicating the streaming format type.  Every MoQ Streaming Format normatively referencing this catalog format MUST register <del> itself in the "MoQ Streaming Format Type" table.  See iana for additional details. </del>  3.2.2.

Reviewer comments:
I suggest creating an IANA registry for catalog fields with values auto-populated from Section 3.2.
What is the point of shifting the catalog fields definitions to IANA? IANA is useful for ensuring global uniqueness. If a single specification defines the catalog format, then that spec if a much more efficient and natural place to define the fields used by that format.
If we end up needing new fields (which we certainly will), we don't need a revised RFC. The fields table can be amended/expanded in a number of ways.

Revised text:
A number indicating the streaming format type.  Every MoQ Streaming Format normatively referencing this catalog format MUST register  <ins> itself in the "MoQ Streaming Format Type" table.  See ianaconsiderations for additional details. </ins> 3.2.2.
Original text:
3.2.3.  An array of track objects trackobject.  If the 'tracks' field is present then the 'catalog' field MUST NOT be present. <del> 3.2.4. </del>  An array of catalog objects catalogobject.  If the 'catalogs' field is present then the 'tracks' field MUST NOT be present.  A catalog MUST NOT list itself in the catalog array. <del> 3.2.5. </del>  A catalog object is a collection of fields whose location is specified as 'RC', 'TC' or 'RTC' in Table 1. <del> 3.2.6. </del>  A track object is a collection of fields whose location is specified as 'RT', 'TC' or 'RTC' in Table 1. <del> 3.2.7. </del>  The name space under which the track name is defined.  See section 2.3 of MoQTransport.  If the track namespace is declared in the root

Reviewer comments:
by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.

Revised text:
3.2.3. <ins> A boolean that if true indicates that the publisher MAY issue incremental (delta) updates - see patch.  If false or absent, then the publisher gaurantees that they will NOT issue any incremental updates and that any future updates to the catalog will be independent.  The default value is false.  This field MUST be present if its value is true, but may be omitted if the value is false. 3.2.4. </ins> An array of track objects trackobject.  If the 'tracks' field is present then the 'catalog' field MUST NOT be present.  <ins> 3.2.5. </ins> An array of catalog objects catalogobject.  If the 'catalogs' field is present then the 'tracks' field MUST NOT be present.  A catalog MUST NOT list itself in the catalog array.  <ins> 3.2.6. </ins> A catalog object is a collection of fields whose location is specified as 'RC', 'TC' or 'RTC' in Table 1.  <ins> 3.2.7. </ins> A track object is a collection of fields whose location is specified as 'RT', 'TC' or 'RTC' in Table 1.  <ins> 3.2.8. </ins> The name space under which the track name is defined.  See section 2.3 of MoQTransport.  If the track namespace is declared in the root
Original text:
optional.  If it is not declared at the root or track level, then each track MUST inherit the namespace of the catalog track. <del> 3.2.8. </del>  A string defining the name of the track.  See section 2.3 of MoQTransport.  Within the catalog, track names MUST be unique per namespace. <del> 3.2.9. </del>  A string defining the type of payload encapsulation.  Allowed values are strings as defined in Table 2. Table 2: Allowed packaging values <del> 3.2.10. </del>  Each track description can specify an optional operation value that identifies the catalog producer's intent.  Track operation is an

Reviewer comments:
by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.

Revised text:
optional.  If it is not declared at the root or track level, then each track MUST inherit the namespace of the catalog track.  <ins> 3.2.9. </ins> A string defining the name of the track.  See section 2.3 of MoQTransport.  Within the catalog, track names MUST be unique per namespace.  <ins> 3.2.10. </ins> A string defining the type of payload encapsulation.  Allowed values are strings as defined in Table 2. Table 2: Allowed packaging values  <ins> 3.2.11. </ins> Each track description can specify an optional operation value that identifies the catalog producer's intent.  Track operation is an
Original text:
The default track operation is 'add'.  This value does not need to be declared in the track object. <del> 3.2.11. </del>  A string defining a human-readable label for the track.  Examples might be "Overhead camera view" or "Deutscher Kommentar".  Note that the JSON spec requires UTF-8 support by decoders. <del> 3.2.12. </del>  An integer specifying a group of tracks which are designed to be rendered together.  Tracks with the same group number SHOULD be

Reviewer comments:
by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.

Revised text:
The default track operation is 'add'.  This value does not need to be declared in the track object.  <ins> 3.2.12. </ins> A string defining a human-readable label for the track.  Examples might be "Overhead camera view" or "Deutscher Kommentar".  Note that the JSON spec requires UTF-8 support by decoders.  <ins> 3.2.13. </ins> An integer specifying a group of tracks which are designed to be rendered together.  Tracks with the same group number SHOULD be
Original text:
accompany one another.  A common example would be tying together audio and video tracks. <del> 3.2.13. </del>  An integer specifying a group of tracks which are alternate versions of one-another.  Alternate tracks represent the same media content,

Reviewer comments:
by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.

Revised text:
accompany one another.  A common example would be tying together audio and video tracks.  <ins> 3.2.14. </ins> An integer specifying a group of tracks which are alternate versions of one-another.  Alternate tracks represent the same media content,
Original text:
be a set video tracks of the same content offered in alternate bitrates. <del> 3.2.14. </del>  A string holding Base64 BASE64 encoded initialization data for the track. <del> 3.2.15. </del>  A string specifying the track name of another track which holds initialization data for the current track.  Initialization tracks

Reviewer comments:
by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.

Revised text:
be a set video tracks of the same content offered in alternate bitrates.  <ins> 3.2.15. </ins> A string holding Base64 BASE64 encoded initialization data for the track.  <ins> 3.2.16. </ins> A string specifying the track name of another track which holds initialization data for the current track.  Initialization tracks
Original text:
only via the initialization track field of the track which they initialize. <del> 3.2.16. </del>  An object holding a series of name/value pairs which a subscriber can use to select tracks for subscription.  If present, the selection

Reviewer comments:
by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.

Revised text:
only via the initialization track field of the track which they initialize.  <ins> 3.2.17. </ins> An object holding a series of name/value pairs which a subscriber can use to select tracks for subscription.  If present, the selection
Original text:
declaration of a selection parameter at the track level overrides the inherited root value. <del> 3.2.17. </del>  Certain tracks may depend on other tracks for decoding.  Dependencies holds an array of track names trackname on which the current track is

Reviewer comments:
by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.

Revised text:
declaration of a selection parameter at the track level overrides the inherited root value.  <ins> 3.2.18. </ins> Certain tracks may depend on other tracks for decoding.  Dependencies holds an array of track names trackname on which the current track is
Original text:
This example shows catalog for a media producer capable of sending 3 time-aligned video tracks for high definition, low definition and medium definition video qualities, along with an audio track.  In <del> this example the namesapce is absent, which infers that each track must inherit the namespace of the catalog. </del>  3.4.3.

Reviewer comments:
by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.

Revised text:
This example shows catalog for a media producer capable of sending 3 time-aligned video tracks for high definition, low definition and medium definition video qualities, along with an audio track.  In  <ins> this example the namespace is absent, which infers that each track must inherit the namespace of the catalog.  Additionally this example shows the presence of the supportsDeltaUpdates flag. </ins> 3.4.3.