jiebi/CodeConvo huggingface dataset:
Code change:
File extension(s): senmlx and sensmlx <ins> Windows Clipboard Name: "XML Sensor Measurement List" for senmlx </ins> Macintosh file type code(s): none <ins> Macintosh Universal Type Identifier code: org.ietf.senml-xml conforms to publc.xml for senmlx </ins> Person & email address to contact for further information: Cullen Jennings <fluffy@iii.ca>

Related discussion:
text: See email from paul L Nov1 to media-types Hello Cullen, it seems to me that all the content-types you have been describing about senML are candidate content types to be exchanged over the clipboard of a normal mobile or desk computer; e.g. from a reading app to another, … Do you agree on this? If yes, then I’d like to recommend to add: MacOS Uniform Type Identiers Windows Clipboard Name for each of the content-types. If there is earlier experience in this realm, probably this should be taken, otherwise, I can probably suggest some clipboard names. Standardising such at the Media-Type declaration level allows to set a reference frame so that other implementations can follow, just as the content-type name. For examples of including this in the media-type registration, see that of SVG or MathML. thanks in advance. Paul
At IETF 97 was "probably should do this" - see URL
See MathML at URL
On the UTI, currently only apple can declare ones in the public space ( see URL ). I do not see how to request one. There is a bunch of extra info apple would need to add to the OS to really make this work outlined in URL
Windows clipboard info at URL(v=vs.85).aspx
Makes sense; no need for a clipboard format for the streaming and compressed versions actually.
Code change:
the connection establishment. With these exceptions, the DTLS message formats, flows, and logic are <del> the same as those of TLS 1.3. </del> <ins> the same as those of TLS 1.3.  DTLS implementations SHOULD not use the TLS 1.3 "compatibility mode" described in I-D.ietf-tls-tls13, Section D.4 and DTLS servers SHOULD ignore the "session_id" value generated by the client rather than sending ChangeCipherSpec messages.  Implementations MUST still ignore ChangeCipherSpec messages received during the handshake and at all other times SHOULD treat them as if they had failed to deprotect. </ins> 5.1.

Related discussion:
text: Right now, my NSS patch for compatibility mode in TLS also includes changes to DTLS. Those changes include the ServerHello format changes, but NSS will ignore the session_id and never send a ChangeCipherSpec from either client or server.
Note that we probably still want to ignore CCS in DTLS - DTLS discards things that it doesn't want to see - this is about generating CCS.
Code change:
6.1. <del> Most major TLS implementations support external PSKs.  And all have a common interface that applications may use when supplying them for individual connections.  Details about existing stacks at the time of writing are below. </del> <ins> Most major TLS implementations support external PSKs.  Stacks supporting external PSKs provide interfaces that applications may use when supplying them for individual connections.  Details about existing stacks at the time of writing are below. </ins> OpenSSL and BoringSSL: Applications specify support for external PSKs via distinct ciphersuites.  They also then configure callbacks that are invoked for PSK selection during the handshake. <del> These callbacks must provide a PSK identity (as a character string) and key (as a byte string).  (If no identity is provided, a default one is assumed.)  They are typically invoked with a PSK hint, i.e., the hint provided by the server as per RFC4279.  The PSK length is validated to be between [1, 256] bytes upon selection. </del> <ins> These callbacks must provide a PSK identity and key.  The exact format of the callback depends on the negotiated TLS protocol version with new callback functions added specifically to OpenSSL for TLS 1.3 RFC8446 PSK support.  The PSK length is validated to be between [1, 256] bytes.  The PSK identity may be up to 128 bytes long. </ins> mbedTLS: Client applications configure PSKs before creating a connection by providing the PSK identity and value inline. <del> Servers must implement callbacks similar to that of OpenSSL.  PSK lengths are validate to be between [1, 16] bytes. </del> <ins> Servers must implement callbacks similar to that of OpenSSL.  Both PSK identity and key lengths may be between [1, 16] bytes long. </ins> gnuTLS: Applications configure PSK values, either as raw byte <del> strings or hexadecimal strings.  The PSK size is not validated. </del> <ins> strings or hexadecimal strings.  The PSK identity and key size are not validated. </ins> wolfSSL: Applications configure PSKs with callbacks similar to OpenSSL.

Related discussion:
text: FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME
Code change:
2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <del> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </del> <ins> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "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. </ins> 3.

Related discussion:
text: Just saving some typing because this section will eventually need to match what's in RFC8174.
Code change:
7.5.3. <del> To prevent accepting replay of previously received notification responses, the client may perform the following procedure after boot: </del> <ins> To prevent accepting replay of previously received notifications, the client may perform the following procedure after boot: </ins> <del> The client rejects notifications bound to the earlier registration, removes all Notification Numbers and re-registers using Observe. </del> <ins> The client forgets about earlier registrations, removes all Notification Numbers and re-registers using Observe. </ins> 8.

Related discussion:
text: Back to one processing description Observe is now primarily inner Simplified processing Explicit cancellation by intermediary not supported
Code change:
4.1.3. <del> The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is </del> <ins> The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf, is </ins> the output session key of a successful EDHOC exchange. <del> Keys for applications are derived using EDHOC_Exporter from PRK_exporter (see exporter) which in turn is derived from PRK_out. For the purpose of generating application keys, it is sufficient to store PRK_out or PRK_exporter.  (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a Trusted Execution Environment, see impl-cons). </del> <ins> Keys for applications are derived using EDHOC_Exporter (see exporter) from PRK_exporter, which in turn is derived from PRK_out as shown in fig-edhoc-kdf.  For the purpose of generating application keys, it is sufficient to store PRK_out or PRK_exporter.  (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a Trusted Execution Environment, see impl-cons). </ins> 4.2. This section defines EDHOC_Exporter in terms of EDHOC_KDF and <del> PRK_out.  A key update function is defined in keyupdate. </del> <ins> PRK_exporter.  A key update function is defined in keyupdate. </ins> 4.2.1.

Related discussion:
text: I strongly think that all 10 EDHOC-KDF should be in the same table The text about maclengthx need to use the defined term hash_length
I made one commit for review.
Code change:
the DTLS signaling, but will instead forward DTLS packets received from an endpoint on to the Key Distributor (and vice versa) via a tunnel established between Media Distributor and the Key Distributor. <del> This tunnel used to encapsulate the DTLS-SRTP signaling between the Key Distributor and endpoints will also be used to convey HBH key </del> <ins> This tunnel is used to encapsulate the DTLS-SRTP signaling between the Key Distributor and endpoints will also be used to convey HBH key </ins> information from the Key Distributor to the Media Distributor, so no additional protocol or interface is required.

Related discussion:
text: Replaced Media with Key distributor in on important place. Replaced the DTLS tunnel with TLS according to the latest tunnel draft. A couple of more wording fixes.
Code change:
PADDING frame implement "Probing using padding data", as defined in Section 4.1 of DPLPMTUD. <del> Endpoints SHOULD set the initial value of BASE_PMTU (see Section 5.1 of DPLPMTUD) to be consistent with the minimum QUIC packet size.  The MIN_PLPMTU is the same as the BASE_PMTU. </del> <ins> Endpoints SHOULD set the initial value of BASE_PLPMTU (Section 5.1 of DPLPMTUD) to be consistent with QUIC's smallest allowed maximum datagram size.  The MIN_PLPMTU is the same as the BASE_PLPMTU. </ins> <del> QUIC endpoints implementing DPLPMTUD maintain a maximum packet size (DPLPMTUD MPS) for each combination of local and remote IP addresses. </del> <ins> QUIC endpoints implementing DPLPMTUD maintain a DPLPMTUD Maximum Packet Size (MPS, Section 4.4 of DPLPMTUD) for each combination of local and remote IP addresses.  This corresponds to the maximum datagram size. </ins> 14.3.1. From the perspective of DPLPMTUD, QUIC is an acknowledged <del> packetization layer (PL).  A sender can therefore enter the DPLPMTUD BASE state when the QUIC connection handshake has been completed. </del> <ins> Packetization Layer (PL).  A QUIC sender can therefore enter the DPLPMTUD BASE state (Section 5.2 of DPLPMTUD) when the QUIC connection handshake has been completed. </ins> 14.3.2. <del> QUIC provides an acknowledged PL, therefore a sender does not implement the DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state; see Section 5.2 of DPLPMTUD. </del> <ins> QUIC is an acknowledged PL, therefore a QUIC sender does not implement a DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state; see Section 5.2 of DPLPMTUD. </ins> 14.3.3.

Related discussion:
text: Section 7.2: "Endpoints SHOULD use an initial congestion window of 10 times the maximum datagram size (maxdatagramsize), limited to the larger of 14720 bytes or twice the maximum datagram size." "maximum datagram size" is not used in Transport there need to be alignment here of what name to use. Transport has Maximum Packet Size, which appears to match the definition in the appendix of maxdatagram_size.
Thanks for your careful review, NAME -- these are good finds! I've addressed your comments below and in . I'll address point 6 in a separate PR. Section 19.3 has the following text, which does tell how to compute acknowledgement delay from the ACK Delay field: I've replaced "computed" with "decoded" in the recovery document to make it clearer. Coalescing applies to packets, not to datagrams. We've explicitly stated that a sender could send 2 datagrams to avoid any effects of coalescing. I think the text is pretty clear on this: "An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets". I've added "sender-side" to make the controller more explicit. To your point about making this a sender requirement, that is covered in the transport doc (end of ):
Based on and , labeling this as "editorial"
I think these issues are resolved once the two PRs are completely ready.
Except for the one erronous exchange of packet this looks good.
Code change:
7.4.1. <del> Additionally to the previous section, the following applies when Observe is supported. 7.4.1.1. A client receiving a notification SHALL compare the Partial IV of a received notification with the Notification Number associated to that Observe registration.  The ordering of notifications after OSCORE processing MUST be aligned with the Partial IV.  The client MAY do so by copying the least significant bytes of the Partial IV into the Observe option, before passing it to CoAP processing.  The client MAY ignore an Outer Observe option value.  If the verification of the response succeeds, and the received Partial IV was greater than the Notification Number, then the client SHALL update the corresponding Notification Number with the received Partial IV.  The client MUST stop processing notifications with a Partial IV which has been previously received.  An application MAY require the client to discard notifications which have Partial IV less than the Notification Number. If messages are processed concurrently, the Partial IV needs to be validated a second time after decryption and before updating the replay protection data.  The operation of validating the Partial IV and updating the replay protection data MUST be atomic. 7.4.1.2. In order to allow intermediaries to re-register their interest in a resource (see 3.3.1 of RFC7641), a server receiving an Observe registration with Token, kid and Partial IV identical to a previously received registration, and which decrypts without error SHALL not treat it as a replay and SHALL respond with a notification.  The notification may be a cached copy of the latest sent notification (with the same Token, kid and Partial IV) or it may be a newly generated notification with a fresh Partial IV. </del> <ins> The following applies additionally when Observe is supported. The Notification Number is initialized to the Partial IV of the first successfully received notification response to the registration request.  A client receiving a notification SHALL compare the Partial IV of a verified notification with the Notification Number associated to that Observe registration.  In contrast to RFC7641, the received Partial IV MUST always be compared with the Notification Number, which thus MUST NOT be forgotten after 128 seconds. If the verification of the response succeeds, and the received Partial IV was greater than the Notification Number, then the client SHALL update the corresponding Notification Number with the received Partial IV.  The operation of validating the Partial IV and updating the replay protection data MUST be atomic.  If the Inner Observe option is empty, then the client SHALL copy the least significant bytes of the Partial IV into the Observe option, before passing it to CoAP processing. If the Partial IV is less than or equal to the Notification Number, then the client SHALL stop processing the response but not cancel the observation. </ins> 7.5.

Related discussion:
text: Back to one processing description Observe is now primarily inner Simplified processing Explicit cancellation by intermediary not supported
Code change:
If an endpoint receives an ADDRESS_REQUEST capsule that contains zero Requested Addresses, it MUST abort the IP proxying request stream. <del> 4.6.3. </del> <ins> 4.7.3. </ins> The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the capsule type) allows an endpoint to communicate to its peer that it

Related discussion:
text: I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.
Code change:
5.4. <del> The DTLS ekt_key is sent using the retransmissions specified in Section 4.2.4.  of DTLS RFC6347. </del> <ins> The DTLS message is sent using the retransmissions specified in Section 4.2.4. of DTLS RFC6347.  Retransmission is finished with an Ack message or an alert is received. </ins> 6.

Related discussion:
text: This is much more compatible with extensibility patterns in TLS stacks, and in a way that is very forward-compatible with the forthcoming DTLS 1.3, while still being implementable in pre-1.3 stacks. DTLS 1.3 has a notion of post-handshake handshake messages, like and , which are acknoweldged with an message. The framework described here simply sends as yet another post-handshake message. Depends on
r? NAME
I have a bunch of comments but really I could live with this like you have it now.
Code change:
QUIC Stream ID for a client-initiated bidirectional stream encoded as a variable-length integer.  A client MUST treat receipt of a GOAWAY frame containing a Stream ID of any other type as a connection error <del> of type HTTP_MALFORMED_FRAME. </del> <ins> of type HTTP_WRONG_STREAM. </ins> Clients do not need to send GOAWAY to initiate a graceful shutdown; they simply stop making new requests.  A server MUST treat receipt of

Related discussion:
text: (Note that the issue identifies two issues, but one was already fixed in .)
In , NAME correctly observed that I messed up , but he closed his PR and I'm not able to reopen it without more git wizardry than I'm interested in practicing today. Easier just to fix it in my own branch.
Clients don't send GOAWAY and when a client sends one, the server treats it as HTTPUNEXPECTEDFRAME. By contrast, servers don't send MAXPUSHID but the client treats receiving one as HTTPMALFORMEDFRAME. By contrast, if GOAWAY is sent on !control it's HTTPUNEXPECTEDFRAME, but if MAXPUSHID is sent on !control, it's HTTPWRONGSTREAM. I think the answers here are HTTPUNEXPECTEDFRAME and HTTPWRONGSTREAM respectively, but we should be consistent.
I think you're correct. There are some situations where newer errors would be more appropriate.
Code change:
"RateLimit-Reset": containing the time remaining in the current window, specified in seconds. <del> The behavior of "RateLimit-Reset" is compatible with the "delta- </del> <ins> The behavior of "RateLimit-Reset" is compatible with the "delay- </ins> seconds" notation of "Retry-After". The fields definition allows to describe complex policies, including

Related discussion:
text: uses http-core semantics fixes Sections refs cc: NAME
I'll wait for the new i-d-template image, but will do.
Please use either [RFCxxxx], Section yyy or Section yyy of [RFCxxxx]
Addressed by now.
If you start using the new kramdown-rcf2629 section ref syntax, you may want to do that consistently...
Code change:
5.2. min_rtt is the sender's estimate of the minimum RTT observed for a <del> given network path.  In this document, min_rtt is used by loss detection to reject implausibly small rtt samples. </del> <ins> given network path over a period of time.  In this document, min_rtt is used by loss detection to reject implausibly small rtt samples. </ins> min_rtt MUST be set to the latest_rtt on the first RTT sample. min_rtt MUST be set to the lesser of min_rtt and latest_rtt (latest-

Related discussion:
text: This should be fixed. I've sent out .
The natural question that follows will be "which period of time", but I think that is already.Thanks, LG
Code change:
only if that object has a member with that name.  Nothing is selected from a value that is not a object. <del> Array indexing via "element-index" is a way of selecting a particular array element using a zero-based index.  For example, selector "[0]" selects the first and selector "[4]" the fifth element of a sufficiently long array. </del> <ins> The "index-selector" applied with an "element-index" to an array selects an array element using a zero-based index.  For example, selector "[0]" selects the first and selector "[4]" the fifth element of a sufficiently long array.  Nothing is selected, and it is not an error, if the index lies outside the range of the array.  Nothing is selected from a value that is not an array. </ins> A negative "element-index" counts from the array end.  For example, selector "[-1]" selects the last and selector "[-2]" selects the

Related discussion:
text: The index selector (but not the index wildcard selector) selects no elements from non-arrays. See URL for background.
This seems implicit since JSON objects cannot be numerically accessed.
Yes, but making it explicit is clearer.
This looks okay, and it aligns the text with the previous paragraph.
Code change:
Additional terms used in this specification are defined below. <ins> 1.1.1. This specification models the argument as a tree of JSON values, each with its own node.  A node is either the root node or one of its descendants. This specification models the result of applying a query to the argument as a nodelist (a list of nodes). So nodes are the selectable parts of the argument.  The only parts of an object that can be selected by a query are the member values. Member names and members (name/value pairs) cannot be selected.  So member values have nodes, but members and member names do not. Similarly, member values are children of an object, but members and member names are not. </ins> 1.2. This section is informative.

Related discussion:
text: This is a draft for us to contemplate and update to see if we can reach a satisfactory clarification.
Thinking about the discussion in and the current definitions ... leads me to the question, why object members can't be nodes. Consider a subtile modification of definitions: Member: A name/value pair in an object. Element: An index/value pair in an array. Node: A pair of a value along with its nodename (member name or element index). Root Node: The unique node with the name "$" whose value is the entire argument. Location: The unique path from the root node to a single node, manifested as a normalized path. This is an alternative node representation, i.e, in nodelists. This way confusing formulations like become obsolete. We also get a more simplified definition for children and anchestors equivalent to child nodes and anchestor nodes. It seems to be consistent to that . Is there something I am overlooking?
We could do this, but that would mean our data model no longer maps to JSON, which doesn't have free-floating members (or elements in the above definition). Also, from a practical point of view, one usually wants to look at a node in the sense we currently have it, not as a combination of the edge leading into it and the vertex itself (in graph theory, node also is usually a synonym to a vertex, not that combination). (I think we already got rid of the confusing wordings.)
That definition of node would not uniquely identify a value in the JSON tree. For instance, in the JSON: the above definition of node says there are two nodes with the value 1 and the nodename 0. This isn't a node, according to the above definition, because it does not have a nodename. In the above JSON example, the Normalized Paths and both point at a single node (with value 1 and the nodename 0). Also, following on from NAME comment, the whole point of JSONPath is to select/extract JSON values from a JSON value, so that rules out selecting/extracting object members, since these are not JSON values.
I am not quite convinced yet. Hmm ... where is it specified, that a node definition must be unique. Nodes in an XML DOM tree aren't either. Object members have an explicit nodename.