jiebi/CodeConvo huggingface dataset:
Change:
this property may be ignored. Safely Replayable: when this is true, this means that the Message <del> can be used by mechanisms that might transfer it multiple times - e.g., as a result of racing multiple transports or as part of TCP Fast Open.  Also, protocols that do not protect against duplicated messages, such as UDP, can only be used with Messages that are Safely Replayable. </del> <ins> can be used by a transport mechanism that might transfer it multiple times - e.g., as a result of racing multiple transports or as part of TCP Fast Open.  Also, protocols that do not protect against duplicated messages, such as UDP (when used directly, without a protocol layered atop), can only be used with Messages that are Safely Replayable.  When a transport system is permitted to replay messages, replay protection could be provided by the application. </ins> Final: when this is true, this means that the sender will not send any further messages.  The Connection need not be closed (in case

Discussion:
Addition to clarify what happens when a transport system replays messages -
The current text says: If true, Safely Replayable specifies that a Message is safe to send to the Remote Endpoint more than once for a single Send Action. It marks the data as safe for certain 0-RTT establishment techniques, where retransmission of the 0-RTT data may cause the remote application to receive the Message multiple times. For protocols that do not protect against duplicated messages, e.g., UDP, all messages need to be marked as "Safely Replayable". To enable protocol selection to choose such a protocol, "Safely Replayable" needs to be added to the TransportProperties passed to the Preconnection. If such a protocol was chosen, disabling "Safely Replayable" on individual messages MUST result in a SendError. — I think this could perhaps be misleading, and suggest: 1. I would like to change /UDP/directly over UDP/ .... because clearly it is possible that a transport such as QUIC also uses UDP, but provides this sort of protection above the UDP layer. 2. This is still written from the perspective of the protocol. I think it is important here to also therefore add a sentence then clarifies that the application might be able to designed to detect and ignore such duplication. ‘Protection from replay of messages could be provided by an application when a transport system replays messages’.
Change:
particular, this can avoid (re-)sending data that relies on a previous transmission that was never received. <ins> the ability to automatically assign messages and connections to underlaying transport connections to utilize multi-streaming and pooled connections. </ins> Allowing applications to interact with messages is backwards- compatible with existings protocols and APIs, as it does not change the wire format of any protocol.  Instead, it gives the protocol

Discussion:
This updates the definition of a TAPS connection to allow a TAPS implementation to do connection pooling and multi-streaming. It removes the limitation from a TAPS connection to relate to exactly one underlying transport connection and hints that underlying transport connections my be created automatically. This is one result of the discussion around PR .
All comments should be addressed – ready for merge
Thanks for the changes! LGTM.
That seems OK, can we fix: / It can also represent a pool of transport protocol instance/ to be /instances/ or whatever the plural is of a transport protocol instance? Gorry
The arch definition of connection should add a sentence to say that there may be multiple flows (MPTCP, MPQUIC, or even connection pooling) below the abstraction. This was assumed but not stated.
May be fixed by PR
Solved by
LGTM modulo the small fixes pointed out by NAME
Change:
attack is bound by the number of valid TCP connections an attacker can open. <del> 10.8.4. </del> <ins> 10.9.4. </ins> As a means of reducing the impact of network ossification, RFC8744 recommends SNI-protection mechanisms be designed in such a way that

Discussion:
One of the motivations for encrypting HRR in was the leaks from cookie values. If we don't go with such a construction (which seems likely) and instead do or , cookies will be in the clear. That means it is instead on the backend servers to construct cookie values without leaking information. This PR provides security considerations to that effect. Unfortunately the requirements on backend servers within a Split Mode deployment are a bit onerous. I suspect, in practice, the answer is that Split Mode deployments cannot even use cookies on the backend server. Between HRRs being rare and stateless HRR being unnecessary over TCP or QUIC, that's hopefully fine. (Note this is different from , which was about the client-facing server being stateless. This applies if the backend server is stateless.)
Change:
9.1.2.2. <del> When sending Messages, applications can add Framer-specific key/value pairs to a MessageContext (msg-ctx).  This mechanism can be used, for example, to set the type of a Message for a TLV format.  The namespace of values is custom for each unique Message Framer. </del> <ins> When sending Messages, applications can add Framer-specific properties to a MessageContext (msg-ctx).  In order to set these properties, the "add" and "get" actions on the MessageContext.  To avoid naming conflicts, the property names SHOULD be prefixed with a namespace referencing the framer implementation or the protocol it implements as described in property-names. This mechanism can be used, for example, to set the type of a Message for a TLV format.  The namespace of values is custom for each unique Message Framer. </ins> When an application receives a MessageContext in a Receive event, it can also look to see if a value was set by a specific Message Framer.

Discussion:
The other option is to tell people to prepend the name of the framer to the property name.
Is the "scope" used for message contexts (9.1.1) ever anything but a framer? If not, could this section just say framer?
We believe that it is the same; if so, "scope" should probably indeed be named "framer". Tommy, could you please check?
I find this a little strange: given that we do have optional parameters, what's the benefit of first introducing the "add" and "get" calls as if the "framer" parameter didn't exist, and then later changing that? It would seem more consistent to me to introduce it where you had the scope parameter before, called "framer", and use a forward reference to say that framers will be explained later.
Change:
The leader begins each round of continuation for a report share based on its locally computed prepare message and the previous PrepareStep from the helper.  If PrepareStep is of type "failed", then the leader <del> marks the report as failed and removes it from the candidate report set and does not process it further.  If the type is "finished", then the leader aborts with "unrecognizedMessage".  [[OPEN ISSUE: This behavior is not specified.]] If the type is "continued", then the leader proceeds as follows. </del> <ins> acts based on the value of the "ReportShareError": If the error is "ReportShareError.report_too_early", then the leader MAY try to re-send the report in a later "AggregateInitializeReq". For any other error, the leader marks the report as failed, removes it from the candidate report set and does not process it further. If the type is "finished", then the leader aborts with "unrecognizedMessage".  If the type is "continued", then the leader proceeds as follows. </ins> Let "leader_outbound" denote the leader's prepare message and "helper_outbound" denote the helper's.  The leader computes the next

Discussion:
Allows helpers to reject reports from too far in the future, matching the leader check detailed in "Upload Requests". We add for this case, and allow the leader to try the report again later. Requires helpers to mark undecodable decrypted input shares as invalid with ().
The DAP specification defines a number of error modes, which ultimately end up mapped to error codes defined in section 3.1. Currently, the specified behavior does not describe how to treat message-deserialization failures, in any of client-aggregator, aggregator-aggregator, or collector-aggregator communications. We should consider specifying this. Initial thoughts: Moving to (with a new error code?) or makes sense to me, for deserialization errors during the aggregation process. It'd be very nice if one "bad" client report didn't fail the entire aggregation job, e.g. we should probably specify behavior that limits the "blast radius" of a badly-serialized message. We could leave this unspecified; I suppose the risk is that different implementations might treat this error mode with different semantics (e.g. some will fail a single report, some will fail the entirety of the aggregation job).
(This fell out of discussion on URL; FWIW, Janus will currently transition a report aggregation to if it fails to decode a message, though of course that's just one implementation's choice.)
Change:
to the WHIP endpoint configured URL. The HTTP POST request will have a content type of application/sdp and <del> contain the SDP offer as body.  The WHIP endpoint will generate an SDP answer and return it on a 201 Accepted response with content type of application/sdp and the SDP answer as body and a Location header pointing to the newly created resource. </del> <ins> contain the SDP offer as the body.  The WHIP endpoint will generate an SDP answer and return a 201 Accepted response with a content type of application/sdp and the SDP answer as the body and a Location header pointing to the newly created resource. </ins> <del> SDP offer SHOULD use the sendonly attribute and the SDP answer MUST use the recvonly attribute. </del> <ins> The SDP offer SHOULD use the sendonly attribute and the SDP answer MUST use the recvonly attribute. </ins> <del> Once a session is setup ICE consent freshness RFC7675 will be used to detect abrupt disconnection and DTLS teardown for session termination by either side. </del> <ins> Once a session is setup, ICE consent freshness RFC7675 will be used to detect abrupt disconnection and DTLS teardown for session termination by either side. </ins> To explicitly terminate the session, the WHIP client MUST perform an <del> HTTP DELETE request to the resource url returned on the Location </del> <ins> HTTP DELETE request to the resource URL returned in the Location </ins> header of the initial HTTP POST.  Upon receiving the HTTP DELETE request, the WHIP resource will be removed and the resources freed on the media server, terminating the ICE and DTLS sessions.

Discussion:
I gave the spec a good read through and would like to propose some minor language edits as my first contribution. Most of these are straight forward such as: WebRTC not webrtc URI not uri signaling not signalling offer/answer not O/A some grammatical changes There is one somewhat significant correction here in that the header on the example WHIP endpoint reply pointed at the RFC for the extension. I believe this is incorrect and the intent is that this points at a WHIP resource. I have updated the example as such.
Change:
the packet number.  If multiple packet number spaces are used, the packet number alone would not guarantee the uniqueness of the nonce. <del> In order to guarantee the uniqueness of the None, the nonce N is </del> <ins> In order to guarantee the uniqueness of the nonce, the nonce N is </ins> calculated by combining the packet protection IV with the packet number and with the path identifier.

Discussion:
(OK, so it's not the biggest contribution I've ever made, but I DID notice it, while reading the master branch ...
This relates to only one typo, so I merge this PR.
Thanks for correcting this!
Change:
entirely. By using a Connection ID, QUIC is designed to be robust to NAT <del> address rebinding after a timeout.  However, some QUIC connections may not be robust to rebinding because the routing infrastructure (in particular, load balancers) uses the address/port four-tuple to direct traffic.  Furthermore, middleboxes with functions other than address translation may still affect the path.  In particular, firewalls will often not admit server traffic for which it has not kept state for corresponding packets from the client. A QUIC application has three strategies to deal with this issue by adjusting idle periods (noting that idle periods and the network idle timeout is distinct from the connection idle timeout, defined as the minimum of the idle timeout parameter in Section 10.1 of QUIC): </del> <ins> address rebinding after a timeout.  However, this only helps if one endpoint maintains availability at the address its peer uses, and the peer is the one to send after the timeout occurs. Some QUIC connections may not be robust to rebinding because the routing infrastructure (in particular, load balancers) uses the address/port four-tuple to direct traffic.  Furthermore, middleboxes with functions other than address translation could still affect the path.  In particular, firewalls will often not admit server traffic for which it has not kept state for corresponding packets from the client. A QUIC application can adjust idle periods to manage the risk of timeout (noting that idle periods and the network idle timeout is distinct from the connection idle timeout, defined as the minimum of the idle timeout parameter in Section 10.1 of QUIC), but then there are three options: </ins> Ignore it, if the application-layer protocol consists only of interactions with no or very short idle periods, or the protocol's

Discussion:
These are pretty big. If you would prefer that I create a PR for each individual commit, that can be done. It turns out that there were a lot of things I found needed work. For instance, this completely redoes the 0-RTT advice.
It did kinda snowball, for which I apologize. I was trying to get something under your nose before I got swamped by meetings. I am also on vacation next week. I'm reading through and there is some really good stuff in the doc. I have started to open issues where I don't think the fixes are so simple.
Aside from the keep-alive tweak and the idempotence change, these are all editorial and LGTM, thanks! The keepalive tweak is also good. Having looked at URL, the text here is a good applicability-appropriate view on what's there now. assuming discussion there converges to mostly the same thing, I'd be happy to merge this. (in the future, no need to make tiny PRs, but splitting into "editorial-rollup" and "substantive editorial changes" would be nice to separate discussion, since the former shouldn't need much of it)Changes look all ready good. Thanks! I just have left one minor comment/question to double-check before we merge.
Change:
Verification of a common preferred cipher suite: The Initiator lists supported cipher suites in order of <del> preference </del> <ins> preference, ending with the selected cipher suite for the session. </ins> The Responder verifies that the selected cipher suite is the first supported cipher suite (or else rejects and states

Discussion:
Addressing
NAME Please check if your comments are addressed.
Yes, especially in [1]. Thanks! [1] URL
-08 contained a definition of CREDx including an example when kid is used. -09 removed that example and replaces it with a RPK by value example. Now it seems like the most important use case is not well specified. This is the use case that leads to message2 being 45 bytes.
In addition the TOFU use case should likely also have a kid. Otherwise the UCCS has to be sent by value every time.
This is solved by just adding a 'kid' in the COSE_Key map
The document should say someting more about COSEKey. If IDCREDx = { 4 : keyidx } identifies a raw COSEKey, is that an error or is CREDx then the COSEKey wrapped in a UCCS without any parameters like sub?
SUITES_R is a name. The type needs to be defined and the table changed. This can be done in PR
The current definition of SUITESI is that the Initiator can chose any truncation of the list of supported cipher suites as long as the selected cipher suite is included. This works and allows the Initiator to give the Responder information about the full list. This is however a bit complex and has led to misunderstandings of the test vectors where several people thought the test vectors were wrong. i.e. the following are all valid I think we should simplify SUITESI by mandating that the last suite in the list is the selected. This makes SUITESI much easier to understand and lowers message size when an array is used. Giving the Responder info is not so important. CDDL
Maybe a recommendation that SUITES_R SHOULD contain all cipher suites that R supports.
Currently SUITESR : [ supported : 2 suite ] / suite We may keep that, or remove "supported" SUITESR : [ 2 suite ] / suite Alternatively, we may define SUITES_I : [ supported : 2* suite ] / suite Any preference?
They should be the same: or And then
This needs to be defined as a CDDL type. suites = [ 2* suite ] / suite See
Change:
a set of links belonging to the host <del> The names of the attributes of the links correspond with the link- format attributes that can be set.  A link has the following attributes: </del> <ins> The host is free to choose links it deems appropriate to be exposed in its ".well-known/core".  Typically, the links describe resources that are served by the host, but the set can also contain links to resources on other servers (see examples in [RFC6690] page 14).  The set does not necessarily contain links to all resources served by the host. </ins> <del> Unique rt (resource type) </del> <ins> A link has the following attributes: </ins> <del> Unique href (URI this link points to) </del> <ins> One or more link relations (expressed as space-separated values in the "rel" attribute, defaulting to "hosts").  They describe a relations between the link context and the link target. </ins> <del> One or more ct (content-types for transport format) </del> <ins> A link context URI ("anchor").  The link context defines the source of the relation, and serves as the Base URI for resolving the target.  It can be relative, in which case it gets resolved against the Base URI of the ".well-known/core" document it was obtained from . It can be absent, in which the Base URI of the document is used as the context. </ins> <del> Optional anchor (URI this link points from; default is the scheme/ authority of the /.well-known/core) </del> <ins> A link target URI ("href", expressed between the angular brackets in link-format).  The link target defines the destination of the relation, and is the topic of all other target attributes.  If it is a relative URI, it gets resolved against the link context URI. </ins> <del> and associated rel (relation) Optional one if (interface description reference) </del> <ins> Other target attributes (eg. resource type (rt), interface (if), cor content-type (ct)).  These provide additional information about the target URI. </ins> The model shown in fig-ER-RD models the contents of the resource directory which contains in addition to /.well-known/core:

Discussion:
This is the documenting text to the changes worked out first on the examples in . It does not (yet) contain explaining overall text, but updates the various smaller mentions of the parameter to fit together. It does change the semantics of using on a registration update, but I believe that the previous wording was not what the original authors had intended. (Previously, an endpoint registering over TCP would need to explicitly repeat its con on every update).
Change:
for detailing what kinds of information are disclosed, and to whom they are exposed. <del> 12. </del> <ins> 11. </ins> Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation

Discussion:
Addresses issue There's no text changes in this PR, text is just moved without modification. Signed-off-by: Dave Thaler
otherwise, the section 4.1 including a lot of content about attester, attesting enviroment and target enviroment are not easy to understand. Or, at least, have some general introduction or reference to section 6 about what is relation between them.
Agree, Section 6 "Two Types of Environments of an Attester" gives the introduction to these terms, but they are used back in section 4.1 "Composite Attester". Something needs to change either move section 6 up, or section 4.1 down.
Change:
The currentDirection property indicates the last negotiated direction for the transceiver's associated m= section.  More specifically, it indicates the RFC3264 directional attribute of the associated m= <del> section in the last applied answer, with "send" and "recv" directions reversed if it was a remote answer.  For example, if the directional attribute for the associated m= section in a remote answer is "recvonly", currentDirection is set to "sendonly". </del> <ins> section in the last applied answer (including provisional answers), with "send" and "recv" directions reversed if it was a remote answer. For example, if the directional attribute for the associated m= section in a remote answer is "recvonly", currentDirection is set to "sendonly". </ins> If an answer that references this transceiver has not yet been applied, or if the transceiver is stopped, currentDirection is set to

Discussion:
is meant to represent "direction in effect", whereas represents "direction the application wants to negotiate". So, the direction that both inspects and modifies should be ; its purpose is to change the application's desired direction for a transceiver, regardless of the current state of negotiation. Also clarifying that also reflects the direction negotiated in a provisional answer, which was the intent (I believe) but wasn't explicitly stated. This is consistent with it being the direction "in effect", since applying a provisional answer allows the endpoint to start sending/receiving media.
NAME do you want to look at this? I believe this is straightforward.
Section 4.1.3, removeTrack, states: This should say "transceiver.direction". Using "currentDirection" doesn't work because it may be null, and it also may result in un-intuitive behavior, where ends up not having any effect and results in a "sendrecv" or "sendonly" direction being negotiated.
Want to make a PR?