jiebi/CodeConvo huggingface dataset:
3.2.3. <ins> An integer indicating the sequence of this catalog object update. The first catalog object produced under a given name|namespace carries a sequence number of zero.  Each successive update of that catalog, either as an independent or delta update, increments the sequence number by one. 3.2.4. </ins> 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> <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. <del> 3.2.5. </del> <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. <del> 3.2.6. </del> <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. <del> 3.2.7. </del> <ins> 3.2.8. </ins> <del> A number specifying the moq-transport object number from which this catalog represents a delta update.  See deltaupdate for additional details.  Absence of this parent sequence number indicates that this catalog is independent and completely describes the content available in the broadcast. </del> <ins> An optional integer specifying the catalog sequence number sequencenumber number from which this catalog represents a delta update.  See deltaupdate for additional details.  Absence of this parent sequence number indicates that this catalog is independent and completely describes the content available in the broadcast. </ins> <del> 3.2.8. </del> <ins> 3.2.9. </ins> The name space under which the track name is defined.  See section 2.3 of MoQTransport.  The track namespace is required to be specified
or catalog object.  A namespace declared in a track object or catalog object overwrites any inherited name space. <del> 3.2.9. </del> <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. <del> 3.2.10. </del> <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 <del> 3.2.11. </del> <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
The default track operation is 'Add'.  This value does not need to be declared in the track object. <del> 3.2.12. </del> <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. <del> 3.2.13. </del> <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
be a set video tracks of the same content offered in alternate bitrates. <del> 3.2.15. </del> <ins> 3.2.16. </ins> A string holding Base64 BASE64 encoded initialization data for the track. <del> 3.2.16. </del> <ins> 3.2.17. </ins> A string specifying the track name of another track which holds initialization data for the current track.  Initialization tracks
the dependencies is assumed to match that of the track declaring the dependencies. <del> 3.2.19. </del> <ins> 3.2.20. </ins> A number identifying the temporal layer/sub-layer encoding of the track, starting with 0 for the base layer, and increasing with higher temporal fidelity. <del> 3.2.20. </del> <ins> 3.2.21. </ins> A number identifying the spatial layer encoding of the track, starting with 0 for the base layer, and increasing with higher fidelity. <del> 3.2.21. </del> <ins> 3.2.22. </ins> A string defining the codec used to encode the track.  For LOC packaged content, the string codec registrations are defined in Sect 3 and Section 4 of WEBCODECS-CODEC-REGISTRY.  For CMAF packaged content, the string codec registrations are defined in XXX. <del> 3.2.22. </del> <ins> 3.2.23. </ins> A string defining the mime type MIME of the track.  This parameter is typically supplied with CMAF packaged content. <del> 3.2.23. </del> <ins> 3.2.24. </ins> A number defining the framerate of the track, expressed as frames per second. <del> 3.2.24. </del> <ins> 3.2.25. </ins> A number defining the bitrate of track, expressed in bits second. <del> 3.2.25. </del> <ins> 3.2.26. </ins> A number expressing the encoded width of the track content in pixels. <del> 3.2.26. </del> <ins> 3.2.27. </ins> A number expressing the encoded height of the video frames in pixels. <del> 3.2.27. </del> <ins> 3.2.28. </ins> The number of audio frame samples per second.  This property SHOULD only accompany audio codecs. <del> 3.2.28. </del> <ins> 3.2.29. </ins> A string specifying the audio channel configuration.  This property SHOULD only accompany audio codecs.  A string is used in order to provide the flexibility to describe complex channel configurations for multi-channel and Next Generation Audio schemas. <del> 3.2.29. </del> <ins> 3.2.30. </ins> A number expressing the intended display width of the track content in pixels. <del> 3.2.30. </del> <ins> 3.2.31. </ins> A number expressing the intended display height of the track content in pixels. <del> 3.2.31. </del> <ins> 3.2.32. </ins> A string defining the dominant language of the track.  The string MUST be one of the standard Tags for Identifying Languages as defined
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> <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.
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> <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.
5. <del> This section details how the MoQ Streaming Format Type can be registered.  The type registry can be updated by incrementally expanding the type space, i.e., by allocating and reserving new type identifiers.  As per [RFC8126], this section details the creation of the "MoQ Streaming Format Type" registry. </del> <ins> This section details how the MoQ Streaming Format Type and new fields can be registered for inclusion in a catalog. </ins> 5.1. This document creates a new registry, "MoQ Streaming Format Type". <del> The registry policy is "RFC Required".  The Type value is 2 octets. The range is 0x0000-0xFFFF.The initial entry in the registry is: </del> <ins> This registry is managed by the IANA according to the RFC Required policy of RFC5226.  The Type value is 2 octets.  The range is 0x0000-0xFFFF.  The initial entry in the registry is: </ins> <del> Every MoQ streaming format draft normatively referencing this catalog format MUST register itself a unique type identifier. </del> <ins> No RFC is provided for the initial entry as it is reserved for Every MoQ streaming format draft normatively referencing this catalog format MUST register itself a unique type identifier.  The type registry can be updated by incrementally expanding by allocating and reserving new type identifiers. 5.2. This document creates a new IANA registry for the Common Catalog fields.  The registry is called "MoQ Common Catalog Fields".  This registry is managed by the IANA according to the Specification Required policy of RFC5226.  The initial entries in the registry are: Any registration for a new Field name MUST provide the following information: Descriptive Name - a descriptive name for the field. Field Name - the JSON field name, as will be used inside the JSON catalog. Required - the string "yes" if the field is required in all catalogs and "opt" if it is not. Location - a string defining the permissible locations for the field within the catalog: 'R' - the field is located in the Root of the JSON object. 'RC' - the field may be located in either the Root or a Catalog object. 'RTC' - the field may be located in either the Root, or a Track object or a Catalog object. 'TC' - the field may be located in either a Track object or a Catalog object. 'RT' - the field may be located in either the Root or a Track object. 'T' - the field is located in a Track object. 'S' - the field is located in the Selection Parameters object. JSON Type - the JSON type of the field value, which must be one of String, Array, Number, Object or Boolean. Specification - a URL to the specification which defines the usage of the field within the catalog, per the Specification Required policy of RFC5226. </ins>
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. <del> 3.2.4. </del> <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. <del> 3.2.5. </del> <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. <del> 3.2.6. </del> <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. <del> 3.2.7. </del> <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
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> <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. <del> 3.2.9. </del> <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 <del> 3.2.10. </del> <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
The default track operation is 'add'.  This value does not need to be declared in the track object. <del> 3.2.11. </del> <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. <del> 3.2.12. </del> <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
be a set video tracks of the same content offered in alternate bitrates. <del> 3.2.14. </del> <ins> 3.2.15. </ins> A string holding Base64 BASE64 encoded initialization data for the track. <del> 3.2.15. </del> <ins> 3.2.16. </ins> A string specifying the track name of another track which holds initialization data for the current track.  Initialization tracks
the dependencies is assumed to match that of the track declaring the dependencies. <del> 3.2.18. </del> <ins> 3.2.19. </ins> A number identifying the temporal layer/sub-layer encoding of the track, starting with 0 for the base layer, and increasing with higher temporal fidelity. <del> 3.2.19. </del> <ins> 3.2.20. </ins> A number identifying the spatial layer encoding of the track, starting with 0 for the base layer, and increasing with higher fidelity. <del> 3.2.20. </del> <ins> 3.2.21. </ins> A string defining the codec used to encode the track.  For LOC packaged content, the string codec registrations are defined in Sect 3 and Section 4 of WEBCODECS-CODEC-REGISTRY.  For CMAF packaged content, the string codec registrations are defined in XXX. <del> 3.2.21. </del> <ins> 3.2.22. </ins> A string defining the mime type MIME of the track.  This parameter is typically supplied with CMAF packaged content. <del> 3.2.22. </del> <ins> 3.2.23. </ins> A number defining the framerate of the track, expressed as frames per second. <del> 3.2.23. </del> <ins> 3.2.24. </ins> A number defining the bitrate of track, expressed in bits second. <del> 3.2.24. </del> <ins> 3.2.25. </ins> A number expressing the encoded width of the track content in pixels. <del> 3.2.25. </del> <ins> 3.2.26. </ins> A number expressing the encoded height of the video frames in pixels. <del> 3.2.26. </del> <ins> 3.2.27. </ins> The number of audio frame samples per second.  This property SHOULD only accompany audio codecs. <del> 3.2.27. </del> <ins> 3.2.28. </ins> A string specifying the audio channel configuration.  This property SHOULD only accompany audio codecs.  A string is used in order to provide the flexibility to describe complex channel configurations for multi-channel and Next Generation Audio schemas. <del> 3.2.28. </del> <ins> 3.2.29. </ins> A number expressing the intended display width of the track content in pixels. <del> 3.2.29. </del> <ins> 3.2.30. </ins> A number expressing the intended display height of the track content in pixels. <del> 3.2.30. </del> <ins> 3.2.31. </ins> A string defining the dominant language of the track.  The string MUST be one of the standard Tags for Identifying Languages as defined
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> <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.
'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> <ins> 'TFC' - the field may be located in either a Track object, the Common Track Fields object or a Catalog object. </ins> <del> 'TC' - the field may be located in either a Track object or a Catalog object. </del> <ins> 'TF' - the field may be located in either a Track object or a Common Track Fields object </ins> <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> <ins> 'T' - the field is located in a Track object </ins> 'S' - the field is located in the Selection Parameters object.
3.2.4. <ins> An object holding a collection of Track Fields (objects with a location of TF or TFC in table 1) which are to be inherited by all tracks.  A field defined at the Track object level always supercedes any value inherited from the Common Track Fields object. 3.2.5. </ins> An array of track objects trackobject.  If the 'tracks' field is present then the 'catalog' field MUST NOT be present. <del> 3.2.5. </del> <ins> 3.2.6. </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. <del> 3.2.6. </del> <ins> 3.2.7. </ins> A catalog object is a collection of fields whose location is <del> specified as 'RC', 'TC' or 'RTC' in Table 1. </del> <ins> specified as 'RC' or 'TFC' in Table 1. </ins> <del> 3.2.7. </del> <ins> 3.2.8. </ins> A track object is a collection of fields whose location is specified <del> as 'RT', 'TC' or 'RTC' in Table 1. </del> <ins> as 'TFC', 'TF' or 'T' in Table 1. </ins> <del> 3.2.8. </del> <ins> 3.2.9. </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
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> <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. <del> 3.2.10. </del> <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 <del> 3.2.11. </del> <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
The default track operation is 'add'.  This value does not need to be declared in the track object. <del> 3.2.12. </del> <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. <del> 3.2.13. </del> <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
Abstract <del> Abstract Text </del> <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. <del> Introduction Text </del> <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.
2. <del> Context </del> <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.
5.1.1. <del> This document requests IANA to add new values to the 'COSE Algorithms' and to the 'COSE Header Algorithm Parameters' registries in the 'Standards Action With Expert Review category. </del> <ins> This document requests IANA to add the following new value to the 'Tree Algorithms' registry: Identifier: TBD_1 Tree Algorithm: ccf_ledger Reference: This document </ins>