jiebi/CodeConvo huggingface dataset:
Characters in the String Value are encoded using a definite length text string (type 3).  Octets in the Data Value are encoded using <del> a definite length byte string (type 2) . </del> <ins> a definite length byte string (type 2). </ins> <del> For compactness, the CBOR representation uses integers for the map keys defined in tbl-cbor-labels.  This table is conclusive, i.e., there is no intention to define any additional integer map keys; any extensions will use string map keys.  This allows translators converting between CBOR and JSON representations to convert also all future labels without needing to update implementations. </del> <ins> For compactness, the CBOR representation uses integers for the labels, as defined in tbl-cbor-labels.  This table is conclusive, i.e., there is no intention to define any additional integer map keys; any extensions will use string map keys.  This allows translators converting between CBOR and JSON representations to convert also all future labels without needing to update implementations. </ins> For streaming SensML in CBOR representation, the array containing <del> the records SHOULD be an CBOR indefinite length array while for non streaming SenML, a definite length array MUST be used. </del> <ins> the records SHOULD be a CBOR indefinite length array while for non-streaming SenML, a definite length array MUST be used. </ins> The following example shows a dump of the CBOR example for the same sensor measurement as in co-ex.
The compressed form, using the byte alignment option of EXI, for the above XML is the following: <del> A small temperature sensor devices that only generates this one EXI </del> <ins> A small temperature sensor device that only generates this one EXI </ins> file does not really need an full EXI implementation.  It can simply hard code the output replacing the 1-wire device ID starting at byte 0x20 and going to byte 0x2F with it's device ID, and replacing the
first record is at position 1.  A range of records can be selected by giving the first and the last record number separated by a '-' character.  Instead of the second number, the '*' character can be <del> used to indicate the last Senml Record in the Pack.  A set of records </del> <ins> used to indicate the last SenML Record in the Pack.  A set of records </ins> can also be selected using a comma separated list of record positions or ranges. (We use the term "selecting a record" for identifying it as part of the fragment, not in the sense of isolating it from the Pack -- the record still needs to be interpreted as part of the Pack, e.g., using <del> the base values defined in record 1.) </del> <ins> the base values defined in earlier records) </ins> 9.1.
Extensions that add a label that is intended for use with EXI need to create a new XSD Schema that includes all the labels in the IANA <del> registry then allocate a new EXI schemaId value.  Moving to the next letter in the alphabet is the suggested way to create the new value for the EXI schemaId.  Any labels with previously blank ID values SHOULD be updated in the IANA table to have their ID set to this new schemaId value. </del> <ins> registry and then allocate a new EXI schemaId value.  Moving to the next letter in the alphabet is the suggested way to create the new value for the EXI schemaId.  Any labels with previously blank ID values SHOULD be updated in the IANA table to have their ID set to this new schemaId value. </ins> Extensions that are mandatory to understand to correctly process the Pack MUST have a label name that ends with the '_' character.
2. The design goal is to be able to send simple sensor measurements in <del> small packets on mesh networks from large numbers of constrained devices.  Keeping the total size of payload under 80 bytes makes this easy to use on a wireless mesh network.  It is always difficult to define what small code is, but there is a desire to be able to implement this in roughly 1 KB of flash on a 8 bit microprocessor. Experience with power meters and other large scale deployments has indicated that the solution needs to support allowing multiple measurements to be batched into a single HTTP or CoAP request.  This "batch" upload capability allows the server side to efficiently support a large number of devices.  It also conveniently supports batch transfers from proxies and storage devices, even in situations where the sensor itself sends just a single data item at a time.  The multiple measurements could be from multiple related sensors or from the same sensor but at different times. </del> <ins> small packets from large numbers of constrained devices.  Keeping the total size of payload small makes it easy to use SenML also in constrained networks, e.g., in a 6LoWPAN RFC4944.  It is always difficult to define what small code is, but there is a desire to be able to implement this in roughly 1 KB of flash on a 8 bit microprocessor.  Experience with power meters and other large scale deployments has indicated that the solution needs to support allowing multiple measurements to be batched into a single HTTP or CoAP request.  This "batch" upload capability allows the server side to efficiently support a large number of devices.  It also conveniently supports batch transfers from proxies and storage devices, even in situations where the sensor itself sends just a single data item at a time.  The multiple measurements could be from multiple related sensors or from the same sensor but at different times. </ins> The basic design is an array with a series of measurements.  The following example shows two measurements made at different times.
fields to provide better information about the statistical properties of the measurement. <ins> In summary, the structure of a SenML record is laid out to support a single measurement per record.  If multiple data values are measured at the same time (e.g., air pressure and altitude), they are best kept as separate records linked through their Time value; this is even true where one of the data values is more "meta" than others (e.g., describes a condition that influences other measurements at the same time). </ins> 4.4. Sometimes it is useful to be able to refer to a defined normalized
as mile, foot, light year are not allowed.  For most cases, the SI unit is preferred. <ins> (Note that some amount of judgement will be required here, as even SI itself is not entirely consistent in this respect.  For instance, for temperature ISO-80000-5 defines a quantity, item 5-1 (thermodynamic temperature), and a corresponding unit 5-1.a (Kelvin), and then goes ahead to define another quantity right besides that, item 5-2 ("Celsius temperature"), and the corresponding unit 5-2.a (degree Celsius).  The latter quantity is defined such that it gives the thermodynamic temperature as a delta from T0 = 275.15 K.  ISO 80000-5 is defining both units side by side, and not really expressing a preference.  This level of recognition of the alternative unit degree Celsius is the reason why Celsius temperatures exceptionally seem acceptable in the SenML units list alongside Kelvin.) </ins> Symbol names that could be easily confused with existing common units or units combined with prefixes should be avoided.  For example, selecting a unit name of "mph" to indicate something that
does not lose any information from the JSON value.  EXI uses the XML types. <del> New entries can be added to the registration by Expert Review as defined in RFC8126.  Experts should exercise their own good judgment but need to consider that shorter labels should have more strict review. </del> <ins> New entries can be added to the registration by either Expert Review or IESG Approval as defined in RFC8126.  Experts should exercise their own good judgment but need to consider that shorter labels should have more strict review.  New entries should not be made that counteract the advice at the end of considerations. </ins> All new SenML labels that have "base" semantics (see senml-base) MUST start with character 'b'.  Regular labels MUST NOT start with that
encryption IV.  The frame counter must be unique and monodically increasing to avoid IV reuse. <del> The frame counter itself can be encoded in a variable length format to decrease the overhead, the following encoding schema is used The first byte in the header is fixed and contains the header metadata S 1 bit Signature flag, indicates the payload contains a signature of set. Reserved (4 bits) Reserved bits LEN (3 bits) The length of the CTR fields in bytes. CTR (Variable length) Frame counter up to 8 bytes long </del> <ins> As each sender will use their own key for encryption, so the SFrame header will include the key id to allow the receiver to identify the key that needs to be used for decrypting. Both the frame counter and the key id are encoded in a variable length format to decrease the overhead, so the first byte in the Sframe header is fixed and contains the header metadata with the following format: Signature flag (S): 1 bit This field indicates the payload contains a signature of set.  Counter Length (LEN): 3 bits This field indicates the length of the CTR fields in bytes.  Extended Key Id Flag (X): 1 bit Indicates if the key field contains the key id or the key length. Key or Key Length: 3 bits This field containts the key id (KID) if the X flag is set to 0, or the key length (KLEN) if set to 1. If X flag is 0 then the KID is in the range of 0-7 and the frame counter (CTR) is found in the next LEN bytes: Key id (KID): 3 bits The key id (0-7).  Frame counter (CTR): (Variable length) Frame counter value up to 8 bytes long. if X flag is 1 then KLEN is the length of the key (KID), that is found after the SFrame header metadata byte.  After the key id (KID), the frame counter (CTR) will be found in the next LEN bytes: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+----------------------+------------- ---------+ |S|LEN |1|KLEN | KID... (length=KLEN) | CTR... (length=LEN) | +-+-+-+-+-+-+-+-+----------------------+----------------------+ Key length (KLEN): 3 bits The key length in bytes.  Key id (KID): (Variable length) The key id value up to 8 bytes long.  Frame counter (CTR): (Variable length) Frame counter value up to 8 bytes long. </ins> 3.2.
3.2.3. <del> The sending client maps the outgoing streams and give them unique indices: 0, 1,.. etc.  As mentioned above SFrame supports up to 16 outgoing stream.  After encoding the frame and before packetizing it, the necessary media metadata will be moved out of the encoded frame buffer, to be used later in the RTP header extension.  The encoded frame, the metadata buffer and the stream index are passed to SFrame encryptor which internally keeps track of the number of frames encrypted so far for that stream.  The encryptor constructs SFrame header using the stream index and frame counter and derive the encryption IV.  The frame is encrypted using the encryption key and the header, encrypted frame and the media metadata are authenticated using the authentication key.  The authentication tag is then truncated (If supported by the cipher suite) and prepended at the end of the ciphertext. </del> <ins> After encoding the frame and before packetizing it, the necessary media metadata will be moved out of the encoded frame buffer, to be used later in the RTP header extension.  The encoded frame and the metadata buffer are passed to SFrame encryptor which internally keeps track of the number of frames encrypted so far.  The encryptor constructs SFrame header using frame counter and key id and derive the encryption IV.  The frame is encrypted using the encryption key and the header, encrypted frame and the media metadata are authenticated using the authentication key.  The authentication tag is then truncated (If supported by the cipher suite) and prepended at the end of the ciphertext. </ins> The encrypted payload is then passed to a generic RTP packetized to construct the RTP packets and encrypts it using SRTP keys for the
5.1.2. <del> The sender of a simulcast stream may use the same SRC for all the simulcast streams from the same media source or use a different SRC for each of them, in any case it is transparent to the SFU which will be able to perform the simulcast layer switching normally.  The senders are already able to receive different SRCs from different participants due to LastN and RTP Stream reuse, so supporting simulcast uses same mechanisms. </del> <ins> When using simulcast, the same input image will produce N different encoded frames (one per simulcat layer) which would be processed inpependently by the frame encryptor and assigned an unique counter for each. </ins> 5.1.3.
4. <del> This specification introduces two extensions to the SUIT envelope and the manifest structure, as motivated in arch. The SUIT envelope is enhanced with a key exchange payload, which is carried inside the suit-protection-wrappers parameter, see envelope- fig.  One or multiple SUIT_Encryption_Info payload(s) are carried within the suit-protection-wrappers parameter.  The content of the SUIT_Encryption_Info payload is explained in AES-KW (for AES-KW) and in HPKE (for HPKE).  When the encryption capability is used, the suit-protection-wrappers parameter MUST be included in the envelope. The manifest is extended with a CEK verification parameter (called suit-cek-verification), see manifest-fig.  This parameter is optional and is utilized in environments where battery exhaustion attacks are a concern.  Details about the CEK verification can be found in cek- verification. </del> <ins> This specification introduces two extensions to the SUIT_Parameters, as motivated in arch. The SUIT manifest is enhanced with a key exchange payload, which is carried within the suit-directive-override-parameters or suit- directive-set-parameters for each encrypted payload.  One SUIT_Encryption_Info is carried with suit-parameter-encryption-info, see parameter-fig.  The content of the SUIT_Encryption_Info is explained in AES-KW (for AES-KW) and in HPKE (for HPKE).  When the encryption capability is used, the SUIT_Encryption_Info parameter MUST be included in the SUIT_Directive. A CEK verification parameter (called suit-parameter-cek- verification), see parameter-fig, also extends the manifest.  This parameter is optional and is utilized in environments where battery exhaustion attacks are a concern.  Details about the CEK verification can be found in cek-verification. </ins> 5.
a RESTful API. Different protocols can be used with RESTful systems, but at the time <del> of writing the most common protocols are HTTP RFC7230 and CoAP </del> <ins> of writing the most common protocols are HTTP RFC9110 and CoAP </ins> RFC7252.  Since RESTful APIs are often lightweight and enable loose coupling of system components, they are a good fit for various Internet of Things (IoT) applications, which in general aim at
3.6. <del> Section 6 of RFC7231 defines a set of Status Codes in HTTP that are </del> <ins> Section 15 of RFC9110 defines a set of Status Codes in HTTP that are </ins> assigned by the server to indicate whether a request was understood and satisfied, and how to interpret the answer.  Similarly, Section 5.9 of RFC7252 defines the set of Response Codes in CoAP. <del> The status codes consist of three digits (e.g., "404" with HTTP or "4.04" with CoAP) where the first digit expresses the class of the code.  Implementations do not need to understand all status codes, but the class of the code must be understood.  Codes starting with 1 are informational; the request was received and being processed (not </del> <ins> The codes consist of three digits (e.g., "404" with HTTP or "4.04" with CoAP) where the first digit expresses the class of the code. Implementations do not need to understand all codes, but the class of the code must be understood.  Codes starting with 1 are informational; the request was received and being processed (not </ins> available in CoAP).  Codes starting with 2 indicate a successful request.  Codes starting with 3 indicate redirection; further action is needed to complete the request (not available in CoAP).  Codes
7. <del> This document has no IANA actions. </del> <ins> 7.1. IANA is requested to update the entry for server_name(0) in the registry for ExtensionType (defined in TLS13) by replacing the value in the "TLS 1.3" column with the value "CH, EE, CR". 7.2. IANA is requested to add the following entries to the registry for Exporter Labels (defined in RFC5705): "EXPORTER-server authenticator handshake context", "EXPORTER-client authenticator finished key" and "EXPORTER-server authenticator finished key". </ins> 8.
The signatures generated with this API cover the context string "Exported Authenticator" and therefore cannot be transplanted into other protocols. <ins> In TLS 1.3 the client can not explicitly learn from the TLS layer whether its Finished message was accepted.  Because the application traffic keys are not dependent on the client's final flight, receiving messages from the server does not prove that the server received the client's Finished.  To avoid disagreement between the client and server on the authentication status of EAs, servers MUST verify the client Finished before sending an EA or processing a received EA. </ins>
Abstract The organizational separation between the operator of a TLS server <del> and the certificate authority can create limitations.  For example, </del> <ins> and the certification authority can create limitations.  For example, </ins> the lifetime of certificates, how they may be used, and the <del> algorithms they support are ultimately determined by the certificate authority.  This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with clients that do not support this specification. </del> <ins> algorithms they support are ultimately determined by the certification authority.  This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with clients that do not support this specification. </ins> 1.
operators to limit the exposure of keys in cases that they do not realize a compromise has occurred.  The risk inherent in cross- organizational transactions makes it operationally infeasible to rely <del> on an external CA for such short-lived credentials.  In OCSP stapling, if an operator chooses to talk frequently to the CA to obtain stapled responses, then failure to fetch an OCSP stapled </del> <ins> on an external CA for such short-lived credentials.  In OCSP stapling (i.e., using the Certificate Status extension types ocsp RFC6066 or ocsp_multi RFC6961), if an operator chooses to talk frequently to the CA to obtain stapled responses, then failure to fetch an OCSP stapled </ins> response results only in degraded performance.  On the other hand, failure to fetch a potentially large number of short lived certificates would result in the service not being available, which
associated signature algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the TLS server operator.  The secret key used to sign a credential <del> corresponds to the public key of the X.509 end-entity certificate. </del> <ins> corresponds to the public key of the TLS server's X.509 end-entity certificate. </ins> A TLS handshake that uses delegated credentials differs from a normal handshake in a few important ways:
It was noted in XPROT that certificates in use by servers that support outdated protocols such as SSLv2 can be used to forge signatures for certificates that contain the keyEncipherment KeyUsage <del> (RFC5280 section 4.2.1.3) In order to prevent this type of cross- </del> <ins> (RFC5280 section 4.2.1.3).  In order to prevent this type of cross- </ins> protocol attack, we define a new DelegationUsage extension to X.509 that permits use of delegated credentials.  (See certificate- requirements.)
private key.  The mechanism proposed in this document allows the delegation to be done off-line, with no per-transaction latency.  The figure below compares the message flows for these two mechanisms with <del> TLS 1.3 I-D.ietf-tls-tls13. </del> <ins> TLS 1.3 I-D.ietf-tls-tls13, where DC is delegated credentials. </ins> These two mechanisms can be complementary.  A server could use credentials for clients that support them, while using LURK to
Many of the use cases for delegated credentials can also be addressed using purely server-side mechanisms that do not require changes to <del> client behavior (e.g., LURK I-D.mglt-lurk-tls-requirements).  These mechanisms, however, incur per-transaction latency, since the front- end server has to interact with a back-end server that holds a private key.  The mechanism proposed in this document allows the delegation to be done off-line, with no per-transaction latency.  The figure below compares the message flows for these two mechanisms with TLS 1.3 I-D.ietf-tls-tls13. </del> <ins> client behavior (e.g., a PKCS#11 interface or a remote signing mechanism KEYLESS).  These mechanisms, however, incur per-transaction latency, since the front-end server has to interact with a back-end server that holds a private key.  The mechanism proposed in this document allows the delegation to be done off-line, with no per- transaction latency.  The figure below compares the message flows for these two mechanisms with TLS 1.3 RFC8446. </ins> These two mechanisms can be complementary.  A server could use credentials for clients that support them, while using LURK to support legacy clients. It is possible to address the short-lived certificate concerns above <del> by automating certificate issuance, e.g., with ACME I-D.ietf-acme- acme.  In addition to requiring frequent operationally-critical interactions with an external party, this makes the server operator dependent on the CA's willingness to issue certificates with sufficiently short lifetimes.  It also fails to address the issues with algorithm support.  Nonetheless, existing automated issuance APIs like ACME may be useful for provisioning credentials within an operator network. </del> <ins> by automating certificate issuance, e.g., with ACME RFC8555.  In addition to requiring frequent operationally-critical interactions with an external party, this makes the server operator dependent on the CA's willingness to issue certificates with sufficiently short lifetimes.  It also fails to address the issues with algorithm support.  Nonetheless, existing automated issuance APIs like ACME may be useful for provisioning credentials within an operator network. </ins> 3. While X.509 forbids end-entity certificates from being used as issuers for other certificates, it is perfectly fine to use them to issue other signed objects as long as the certificate contains the <del> digitalSignature KeyUsage (RFC5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that are needed for this application.  The credential has the following </del> <ins> digitalSignature KeyUsage (RFC 5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that are needed for this application.  The credential has the following </ins> structure: Relative time in seconds from the beginning of the delegation
1. <ins> Server operators often deploy TLS termination services in locations such as remote data centers or Content Delivery Networks (CDNs) where it may be difficult to detect key compromises.  Short-lived certificates may be used to limit the exposure of keys in these cases. However, short-lived certificates need to be renewed more frequently than long-lived certificates.  If an external CA is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients. With short-lived certificates, there is a smaller window of time to renew a certificates and therefore a higher risk that an outage at a CA will negatively affect the uptime of the service. </ins> Typically, a TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or CA) RFC8446 RFC5280.  This organizational separation makes the TLS