jiebi/TextFlow huggingface dataset:
Original text:
This example shows the catalog for a media producer that is outputting two streaming formats simultaneously under different namespaces.  Note that each track name referenced points at another <del> catalog object. </del>  4.

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 the catalog for a media producer that is outputting two streaming formats simultaneously under different namespaces.  Note that each track name referenced points at another  <ins> catalog object and that only the first catalog supports incremental delta updates. </ins> 4.
Original text:
'RC' - the field may be located in either the Root or a Catalog object. <del> 'RTC' - the field may be located in either the Root, or a Track object or a Catalog object. </del>  <del> 'TC' - the field may be located in either a Track object or a Catalog object. </del>  <del> 'RT' - the field may be located in either the Root or a Track object. 'T' - the field is located in a Track object. </del>  'S' - the field is located in the Selection Parameters object.

Reviewer comments:
Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example:

Revised text:
'RC' - the field may be located in either the Root or a Catalog object.  <ins> 'TFC' - the field may be located in either a Track object, the Common Track Fields object or a Catalog object. </ins>  <ins> 'TF' - the field may be located in either a Track object or a Common Track Fields object </ins>  <ins> 'T' - the field is located in a Track object </ins> 'S' - the field is located in the Selection Parameters object.
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.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 an

Reviewer comments:
Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example:

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.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 an
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:
Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example:

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:
Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example:

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:
Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example:

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:
Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example:

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:
Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example:

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:
This example shows catalog for a sports broadcast sending time- aligned audio and video tracks using CMAF packaging.  Init segments <del> are delivered as inband data. </del>  3.4.10.

Reviewer comments:
Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example:

Revised text:
This example shows catalog for a sports broadcast sending time- aligned audio and video tracks using CMAF packaging.  Init segments  <ins> are delivered as inband data.  The data has been truncated for clarity. </ins> 3.4.10.
Original text:
Abstract <del> Abstract Text </del>  1. <del> Introduction Text </del>  1.1.

Reviewer comments:
Thanks for the reviews, I have addressed all the comments.
NAME I don't see any reason not to merge.
okay to merge after all suggestions are accepted and remaining comments are acknowledged

Revised text:
Abstract  <ins> This document describes a tree algorithm for COSE Signed Merkle Tree Proofs specifically designed for implementations that rely on Trusted Execution Environments (TEEs) to make the tree more tamper-resistant. </ins> 1.  <ins> The Concise Encoding of Signed Merkle Tree Proofs (CoMeTre) I- D.steele-cose-merkle-tree-proofs defines a standard format for carrying COSE-encoded Merkle Tree proofs and the associated signed root value.  This is helpful to pove to a verifier that a given serializable element is recorded at a given index in the Merkle Tree, or to prove that a tree is an extension of another. In this document, we describe how to verify such CoMeTre proofs for a new type of trees associated with the Confidential Consortium Framework (CCF).  Compared to RFC9162, the leaves of CCF trees carry additional opaque infomation that is used to verify that elements are only written by the Trusted Execution Environment, which addresses the persistance of committed transactions that happen between new signatures of the Merkle Tree root. </ins> 1.1.
Original text:
2. <del> Context </del>  3.

Reviewer comments:
Thanks for the reviews, I have addressed all the comments.
NAME I don't see any reason not to merge.
okay to merge after all suggestions are accepted and remaining comments are acknowledged

Revised text:
2.  <ins> Recall the definition of CoMeTre inclusion proofs, which are parametrized by 3 CBOR data types that are specific to the Tree Algorithm: This document defines the "CCF-leaf" and "CCF-inclusion-proof" CBOR types.  The signed Merkle Root data type "smtr" is the same as in I- D.steele-cose-merkle-tree-proofs but MUST set the protected header parameter carrying the identifier of the tree algorithm, "tree_alg", to the value TBD_1. 2.1. The input of the Merkle Tree Hash (MTH) function is a list of n bytestrings, written D_n = {d[0], d[1], ..., d[n-1]}. The output is a single HASH_SIZE bytestring, also called the tree root hash. This function is defined as follows: The hash of an empty list is the hash of an empty string: The hash of a list with one entry (also known as a leaf hash) is: For n > 1, let k be the largest power of two smaller than n (i.e., k < n <= 2k).  The Merkle Tree Hash of an n-element list D_n is then defined recursively as: where: || denotes concatenation : denotes concatenation of lists D[k1:k2] = D'_(k2-k1) denotes the list {d'[0] = d[k1], d'[1] = d[k1+1], ..., d'[k2-k1-1] = d[k2-1]} of length (k2 - k1). 2.2. Each leaf in a CCF Merkle Tree carries the following components: The "internal_hash" and "internal_data" bytestrings are internal to the CCF implementation.  Similarly, the auxiliary tree entries are internal to CCF.  They are opaque to receipt Verifiers, but they commit the TS to the whole tree contents and may be used for additional, CCF-specific auditing. 2.3. CCF inclusion proofs are one of the tree-specific fields of a "signed-inclusion-proof".  They consist of a list of digests tagged with a single left-or-right bit. Unlike some other tree algorithms, the index of the element in the tree is not explicit in the inclusion proof, but the list of left-or- right bits can be treated as the binary decomposition of the index, from the least significant (leaf) to the most significant (root). 2.4. When a client has received an inclusion proof and wishes to verify inclusion of a signed inclusion proof: 2.5. TBD </ins> 3.