jiebi/CodeConvo huggingface dataset:
The entries in iana-setting-table are registered by this document. <del> For fomatting reasons, setting names can be abbreviated by removing the 'SETTING_' prefix. </del> <ins> For formatting reasons, setting names can be abbreviated by removing the 'SETTINGS_' prefix. </ins> Each code of the format "0x1f * N + 0x21" for non-negative integer values of "N" (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe)
bytes.  An endpoint that includes this parameter supports the DATAGRAM frame types and is willing to receive such frames on this connection.  Endpoints MUST NOT send DATAGRAM frames until they have <del> sent and received the max_datagram_frame_size transport parameter. Endpoints MUST NOT send DATAGRAM frames of size strictly larger than the value of max_datagram_frame_size the endpoint has received from its peer.  An endpoint that receives a DATAGRAM frame when it has not sent the max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  An endpoint that receives a DATAGRAM frame that is strictly larger than the value it sent in its max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  Endpoints that wish to use DATAGRAM frames need to ensure they send a max_datagram_frame_size value sufficient to allow their peer to use them.  It is RECOMMENDED to send the value 65536 in the max_datagram_frame_size transport parameter as that indicates to the peer that this endpoint will accept any DATAGRAM frame that fits inside a QUIC packet. </del> <ins> received the max_datagram_frame_size transport parameter.  Endpoints MUST NOT send DATAGRAM frames of size strictly larger than the value of max_datagram_frame_size the endpoint has received from its peer. An endpoint that receives a DATAGRAM frame when it has not sent the max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  An endpoint that receives a DATAGRAM frame that is strictly larger than the value it sent in its max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  Endpoints that wish to use DATAGRAM frames need to ensure they send a max_datagram_frame_size value sufficient to allow their peer to use them.  It is RECOMMENDED to send the value 65536 in the max_datagram_frame_size transport parameter as that indicates to the peer that this endpoint will accept any DATAGRAM frame that fits inside a QUIC packet. The max_datagram_frame_size transport parameter is a unidirectional limit and indication of support of DATAGRAM frames.  Application protocols that use DATAGRAM frames MAY choose to only negotiate and use them in a single direction. </ins> When clients use 0-RTT, they MAY store the value of the server's max_datagram_frame_size transport parameter.  Doing so allows the
to receiving packets that only contain DATAGRAM frames, since the timing of these acknowledgements is not used for loss recovery. <ins> As with any ack-eliciting frame, when a sender suspects that a packet containing only DATAGRAM frames has been lost, it MAY send probe packets to elicit a faster acknowledgement as described in Section 6.2.4 of RFC9002. </ins> If a sender detects that a packet containing a specific DATAGRAM frame might have been lost, the implementation MAY notify the application that it believes the datagram was lost.
capitals, as shown here. This document uses the Augmented BNF defined in RFC5234 and updated <del> by RFC7405 along with the "#rule" extension defined in Section 7 of MESSAGING. </del> <ins> by RFC7405 along with the "#rule" extension defined in Section 5.6.1 of SEMANTICS. </ins> <del> The term Origin is to be interpreted as described in RFC6454 section 7. </del> <ins> The term Origin is to be interpreted as described in Section 7 of RFC6454. </ins> <del> The "delta-seconds" rule is defined in CACHING section 1.2.1. </del> <ins> The "delay-seconds" rule is defined in Section 10.2.4 of SEMANTICS. </ins> 2.
The header value is <del> The delta-seconds format is used because: </del> <ins> The delay-seconds format is used because: </ins> it does not rely on clock synchronization and is resilient to clock adjustment and clock skew between client and server (see <del> SEMANTICS Section 4.1.1.1); </del> <ins> Section 5.6.7 of SEMANTICS); </ins> it mitigates the risk related to thundering herd when too many clients are serviced with the same timestamp.
8.3.1. <del> The server does not expose "RateLimit-Remaining" values, but resets the limit counter every second. </del> <ins> The server does not expose "RateLimit-Remaining" values (for example, because the underlying counters are not available).  Instead, it resets the limit counter every second. </ins> It communicates to the client the limit of 10 quota-units per second always returning the couple "RateLimit-Limit" and "RateLimit-Reset".
quotas. This was partially addressed by the "Retry-After" header field <del> defined in SEMANTICS to be returned in "429 Too Many Requests" (see STATUS429) or "503 Service Unavailable" responses. </del> <ins> defined in SEMANTICS to be returned in 429 (Too Many Request) (see STATUS429) or 503 (Service Unavailable) responses. </ins> Widely deployed quota mechanisms limit the number of acceptable requests in a given time window, e.g. 10 requests per second;
The term Origin is to be interpreted as described in Section 7 of RFC6454. <del> This specification uses Structured Fields SF to specify syntax. The terms sf-list, sf-item, sf-string, sf-token, sf-integer, bare- item and key refer to the structured types defined therein. </del> <ins> This document uses the following terminology from Section 3 of SF to specify syntax and parsing: List, Item, String, Token and Integer together with the concept of bare item. </ins> 2.
A time window is expressed in seconds, using the following syntax: <del> Where "delay-seconds" is a non-negative sf-integer compatible with the "delay-seconds" rule defined in Section 10.2.3 of SEMANTICS. </del> <ins> Where "delay-seconds" is a non-negative Integer compatible with the "delay-seconds" rule defined in Section 10.2.3 of SEMANTICS. </ins> Subsecond precision is not supported.
otherwise gathered metrics) to better estimate the "RateLimit-Reset" moment intended by the server. <del> The "quota-policy" values and comments provided in "RateLimit-Limit" are informative and MAY be ignored. </del> <ins> The details provided in "RateLimit-Policy" are informative and MAY be ignored. </ins> If a response contains both the "RateLimit-Reset" and "Retry-After" fields, "Retry-After" MUST take precedence and "RateLimit-Reset" MAY
If the client exceeds that limit, it MAY not be served. <del> The field is a List Structured Field of positive length.  The first member is named "expiring-limit" and its syntax is "service-limit", while the syntax of the other optional members is "quota-policy" </del> <ins> The field is a non-negative Integer.  Its value is named "expiring- limit". </ins> The "expiring-limit" value MUST be set to the "service-limit" that is <del> closer to reach its limit. The "quota-policy" is defined in quota-policy, and its values are informative. A "time-window" associated to "expiring-limit" can be communicated via an optional "quota-policy" value, like shown in the following example If the "expiring-limit" is not associated to a "time-window", the "time-window" MUST either be: </del> <ins> closer to reach its limit, and the associated "time-window" MUST either be: </ins> inferred by the value of "RateLimit-Reset" at the moment of the reset, or communicated out-of-band (e.g. in the documentation). <ins> The "RateLimit-Policy" field (see ratelimit-policy-field), might contain information on the associated "time-window". This field MUST NOT occur multiple times and can be sent in a trailer section. 5.2. The "RateLimit-Policy" response field indicates the "quota" associated to the client and its value is informative. The field is a non-empty List of quota policies (see quota-policy). A "time-window" associated to "expiring-limit" can be communicated via "RateLimit-Policy", like shown in the following example. </ins> Policies using multiple quota limits MAY be returned using multiple "quota-policy" items, like shown in the following two examples: This field MUST NOT occur multiple times and can be sent in a trailer section. <del> 5.2. </del> <ins> 5.3. </ins> The "RateLimit-Remaining" response field indicates the remaining "quota-units" defined in service-limit associated to the client. <del> The field is an Integer Structured Field and its value is </del> <ins> The field is a non-negative Integer expressed in "quota-units". </ins> This field MUST NOT occur multiple times and can be sent in a trailer section.
One example of "RateLimit-Remaining" use is below. <del> 5.3. The "RateLimit-Reset" response field indicates either </del> <ins> 5.4. </ins> <del> the number of seconds until the quota resets. </del> <ins> The "RateLimit-Reset" response field indicates the number of seconds until the quota resets. </ins> <del> The field is an Integer Structured Field and its value is </del> <ins> The field is a non-negative Integer. </ins> The delay-seconds format is used because:
operations, and "core.rd-group" is used to discover the URI path for RD Group operations.  Upon success, the response will contain a payload with a link format entry for each RD function discovered, <del> indicating the URI path of the RD function returned and the corresponding Resource Type.  When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. </del> <ins> indicating the URI of the RD function returned and the corresponding Resource Type.  When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. </ins> A Resource Directory MAY provide hints about the content-formats it supports in the links it exposes or registers, using the "ct" link
An RD implementation of this specification MUST support query filtering for the rt parameter as defined in RFC6690. <ins> While the link targets in this discovery step are often expressed in path-absolute form, this is not a requirement.  Clients SHOULD therefore accept URIs of all schemes they support, both in absolute and relative forms, and not limit the set of discovered URIs to those hosted at the address used for URI discovery. </ins> The URI Discovery operation can yield multiple URIs of a particular resource type.  The client may use any of the discovered addresses initially.
on its configuration. The registration message is a list of links to registration resources <del> of the endpoints that belong to that group.  The endpoints MAY be hosted by a different RD than the the group hosting RD.  In that case the endpoint link points to the registration resource on the other RD. </del> <ins> of the endpoints that belong to that group.  The registration resources MAY be located on different hosts than the group hosting RD.  In that case the endpoint link points to the registration resource on the other RD.  The commissioning tool SHOULD NOT attempt to enter a foreign registration in a group unless it found it in the group RD's lookup results, or has other reasons to assume that the foreign registration will be accepted. </ins> The commissioning tool SHOULD not send any target attributes with the links to the registration resources, and the resource directory
does not need to make them accessible to clients.  Clients SHOULD NOT attempt to dereference or manipulate them. <ins> A Resource Directory can report endpoints or groups in lookup that are not hosted at the same address.  While the setup and management of such a distributed system is out of scope for this document, lookup clients MUST be prepared to see arbitrary URIs as registration or group resources in the results. </ins> 7.3. Using the Accept Option, the requester can control whether this list
associated domain of the registration. <del> A Context is a base URL that gives scheme and (typically) authority information about an Endpoint.  The Context of an Endpoint is provided at registration time, and is used by the Resource Directory to resolve relative references inside the registration into absolute URIs.  This is a distinct concept from the "link context" defined in RFC8288. </del> <ins> A Context is a base URL that typically gives scheme and authority information about an Endpoint.  The Context of an Endpoint is provided at registration time, and is used by the Resource Directory to resolve relative references inside the registration into absolute URIs.  This is a distinct concept from the "link context" defined in RFC8288. </ins> The target of a link is the destination address (URI) of the link.
Context (optional).  This parameter sets the Default Base URI under which the request's links are to be interpreted.  The <del> specified URI MUST NOT have a path component of its own, but MUST be suitable as a base URI to resolve any relative </del> <ins> specified URI typically does not have a path component of its own, and MUST be suitable as a base URI to resolve any relative </ins> references given in the registration.  The parameter is <del> therefore of the shape "scheme://authority" for HTTP and CoAP URIs.  In the absence of this parameter the scheme of the protocol, source address and source port of the registration request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an commissioning tool.  If the endpoint uses an ephemeral port to register with, it MUST include the con parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. </del> <ins> therefore usually of the shape "scheme://authority" for HTTP and CoAP URIs.  In the absence of this parameter the scheme of the protocol, source address and source port of the registration request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an commissioning tool.  If the endpoint uses an ephemeral port to register with, it MUST include the con parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. Endpoints that register with a con that contains a path component need to carefully consider the rules of relative URI resolution.  Typically, links submitted by such an endpoint are of the "path-noscheme" form. </ins> Additional registration attributes (optional).  The endpoint can pass any parameter registered at iana-registry to the
[ The RFC editor is asked to replace MCD1 and MCD2 with the assigned addresses throughout the document. ] <ins> 9.6. IANA is asked to extend the reference for the "core" URI suffix in the "Well-Known URIs" registry to reference this document next to RFC6690, as this defines the resource's behavior for POST requests. </ins> 10. Two examples are presented: a Lighting Installation example in lt-ex
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in RFC2119.  The term "byte" is used in its now customary sense as a synonym for "octet". </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. The term "byte" is used in its now customary sense as a synonym for "octet". </ins> This specification requires readers to be familiar with all the terms and concepts that are discussed in RFC3986, RFC8288 and RFC6690.
they do not limit what a server may respond under atypical circumstances. <del> REST clients (registrant-EPs / CTs, lookup clients, RD servers during simple registrations) MUST be prepared to receive any unsuccessful code and act upon it according to its definition, options and/or payload to the best of their capabilities, falling back to failing the operation if recovery is not possible.  In particular, they should retry the request upon 5.03 (Service Unavailable; 503 in HTTP) according to the Max-Age (Retry-After in HTTP) option, and fall back to link-format when receiving 4.15 (Unsupported Content-Format; 415 in HTTP). </del> <ins> REST clients (registrant-EPs and CTs during registration and maintenance, lookup clients, RD servers during simple registrations) MUST be prepared to receive any unsuccessful code and act upon it according to its definition, options and/or payload to the best of their capabilities, falling back to failing the operation if recovery is not possible.  In particular, they should retry the request upon 5.03 (Service Unavailable; 503 in HTTP) according to the Max-Age (Retry-After in HTTP) option, and fall back to link-format when receiving 4.15 (Unsupported Content-Format; 415 in HTTP). </ins> A resource directory MAY make the information submitted to it available to further directories, if it can ensure that a loop does
IPv4 - "all CoRE resource directories" address MCD2 (suggestion: 224.0.1.189), from the "IPv4 Multicast Address Space Registry".  As the address is used for discovery that may span beyond a single <del> network, it has come from the Internetwork Control Block (224.0.1.x, RFC 5771). </del> <ins> network, it has come from the Internetwork Control Block (224.0.1.x) RFC5771. </ins> IPv6 - "all CoRE resource directories" address MCD1 (suggestions FF0X::FE), from the "IPv6 Multicast Address Space Registry", in the
depending on their current availability and capabilities as well as application requirements, thus avoiding silo like solutions.  One of the crucial enablers of such design is the ability to discover <del> resources (machines -- endpoints) capable of providing required information at a given time or acting on instructions from the end users. </del> <ins> resources (and thus the endpoints they are hosted on) capable of providing required information at a given time or acting on instructions from the end users. </ins> Imagine a scenario where endpoints installed on vehicles enable tracking of the position of these vehicles for fleet management
For cases where the device is not specifically configured with a way to find an RD, the network may want to provide a suitable default. <del> If the address configuration of the network is performed via SLAAC, this is provided by the RDAO option rdao. </del> <ins> The IPv6 Neighbor Discovery option RDAO rdao can do that. </ins> <del> If the address configuration of the network is performed via DHCP, this could be provided via a DHCP option (no such option is defined at the time of writing). </del> <ins> When DHCP is in use, this could be provided via a DHCP option (no such option is defined at the time of writing). </ins> Finally, if neither the device nor the network offers any specific configuration, the device may want to employ heuristics to find a
name and the same value, allowing for a trailing "*" wildcard operator as in Section 4.1 of RFC6690.  Attributes that are defined as "link-type" match if the search value matches any of their values <del> (see Section 4.1 of RFC6690; e.g. "?if=core.s" matches ";if="abc core.s";").  A resource link also matches a search criterion if its endpoint would match the criterion, and vice versa, an endpoint link matches a search criterion if any of its resource links matches it. </del> <ins> (see Section 4.1 of RFC6690; e.g. "?if=tag:example.net,2020:sensor" matches ";if="example.regname tag:example.net,2020:sensor";").  A resource link also matches a search criterion if its endpoint would match the criterion, and vice versa, an endpoint link matches a search criterion if any of its resource links matches it. </ins> Note that "href" is a valid search criterion and matches target references.  Like all search criteria, on a resource lookup it can
is specified in the coap-group resource. The presence sensor can learn the presence of groups that support <del> resources with rt=light in its own sector by sending the same request, as used by the luminary.  The presence sensor learns the multicast address to use for sending messages to the luminaries. </del> <ins> resources with rt=tag:example.com,2020:light in its own sector by sending the same request, as used by the luminary.  The presence sensor learns the multicast address to use for sending messages to the luminaries. </ins> 10.2.
at the CoAP layer then it may be inclined to use the endpoint name for looking up what information to provision to the malicious device. <del> Endpoint authentication needs to be checked independently of whether there are configured requirements on the credentials for a given endpoint name (secure-ep) or whether arbitrary names are accepted (arbitrary-ep). </del> <ins> Endpoint authorization needs to be checked on registration and registration resource operations independently of whether there are configured requirements on the credentials for a given endpoint name (secure-ep) or whether arbitrary names are accepted (arbitrary-ep). </ins> Simple registration could be used to circumvent address-based access control: An attacker would send a simple registration request with
and its links. <del> Commissioning Tool (CT) is a device that assists during the installation of the network by assigning values to parameters, naming endpoints and groups, or adapting the installation to the needs of the applications. </del> <ins> Commissioning Tool (CT) is a device that assists during installation events by assigning values to parameters, naming endpoints and groups, or adapting the installation to the needs of the applications. </ins> Registrant-ep is the endpoint that is registered into the RD.  The
resource returned by the initial registration operation. An update MAY update registration parameters like lifetime, base URI <del> or others.  Parameters that are not being changed SHOULD NOT be </del> <ins> or others.  Parameters that are not being changed should not be </ins> included in an update.  Adding parameters that have not changed increases the size of the message but does not have any other <del> implications.  Parameters MUST be included as query parameters in an </del> <ins> implications.  Parameters are included as query parameters in an </ins> update operation as in registration. A registration update resets the timeout of the registration to the
URIs and relative references, and not limit the set of discovered URIs to those hosted at the address used for URI discovery. <ins> With security policies where the client requires the RD to be authorized to act as an RD, that authorization may be limited to resources on which the authorized RD advertises the adequate resource types.  Clients that have obtained links they can not rely on yet can repeat the URI discovery step at the /.well-known/core resource of the indicated host to obtain the resource type information from an authorized source. </ins> The URI Discovery operation can yield multiple URIs of a given resource type.  The client of the RD can use any of the discovered addresses initially.