jiebi/CodeConvo huggingface dataset:
Code change:
set to 0. A QUIC packet with a short header includes a Destination Connection <del> ID.  The short header does not include the Connection ID Lengths, Source Connection ID, or Version fields. </del> <ins> ID immediately following the first byte.  The short header does not include the Connection ID Lengths, Source Connection ID, or Version fields.  The length of the Destination Connection ID is not specified in packets with a short header and is not constrained by this specification. </ins> The remainder of the packet has version-specific semantics.

Related discussion:
text: Invariants text was unclear on where the Destination Connection ID field was and how big it could be.
Section 4.2 of the Invariant Short header are not explicit that the Destionation CID follows the first byte: "A QUIC packet with a short header includes a Destination Connection ID. The short header does not include the Connection ID Lengths, Source Connection ID, or Version fields." As see it just says that the destination CID is part of the short header, not where to find it.
Also the length of the DCID in the short header is unclear. With the long header's restriction on both source and destination CID I don't think the CID is of arbitrary length as stated in Section 4.3. I think it is 0 to 18 bytes long as set agreed by the connection.
Yes, DCID follows the first octet, and we should say that. As for the length, 0/4-18 is a restriction that we agreed applies only to long headers. You can - if the QUIC version allows it - negotiate other lengths for connection IDs using other methods.
Ok, the spec is in some sense clear that this can be of arbitary length. However, that this is not required to be consistent with the long header is far from obvious and probably should be explicitly remarked. An realization I didn't have before over this design is that a given destination IP address and UDP port that deals with multiple QUIC connections will be foreced to use one commond DCID length across all QUIC connections using that port, otherwise it will have to use prefixes for DCIDs to be able to determine how long the actual DCID field are to enable decoding the header protection. It might have been a misstake to not include an DCID length field.
The endpoint can decide on its own DCID length encoding, so that is fine.
One editorial suggestion, but LG
Code change:
fingerprint of the DTLS-SRTP certificate used for the call.  This certificate is unique for a given call and a conference.  This allows the Key Distributor to ensure that only authorized users participate <del> in the conference.  Similarly the Key Distributor can create a WeBRTC Identity assertion bound the fingerprint of the unique certificate </del> <ins> in the conference.  Similarly the Key Distributor can create a WebRTC Identity assertion to bind the fingerprint of the unique certificate </ins> used by the Key Distributor for this conference so that the endpoint can validate it is talking to the correct Key Distributor.

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:
The server ID will start in the second octet of the decrypted connection ID and occupy continuous octets beyond that. <del> The configuration agent selects a zero-padding length.  This SHOULD be at least four octets to allow detection of non-compliant DCIDs. The server ID and zero- padding length MUST sum to no more than 16 octets.  They SHOULD sum to no more than 12 octets, to provide servers adequate space to encode their own opaque data. </del> <ins> They server ID length MUST be no more than 16 octets and SHOULD sum to no more than 12 octets, to provide servers adequate space to encode their own opaque data. </ins> The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption.

Related discussion:
text: The encrypted CID format includes a zero-pad field that is used to detect whether the decryption succeeded or not. I suggest merging this field with the server ID field, and test whether the decryption succeed by checking whether the server ID is valid or not. This assumes that the server ID field is sparsely populated. For example, if there are just 256 servers, in theory a 1-octed field would be sufficient; instead, we could use a 4 or 5 octet server ID field that would be sparsely populated, allowing for error detection. This would allow for unified validity detection across all supported methods: clear text: verify that the server ID is valid; obfuscated: the divider need to have the same size as the full length server ID; the modulo is the server ID; validity can be verified there. stream: decrypt and verify that the server-id is valid encrypt: decrypt and verify that the server-id is valid It would also allows for simplification of the configuration for the encrypted method, by specifying just one field instead of two.
Yes, I agree this is simpler with no cost at all. Care to do a PR?
Code change:
certificate, rendering it unacceptable. A field in the handshake was out of range or inconsistent with <del> other fields.  This alert is always fatal. </del> <ins> other fields. </ins> A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not <del> be located or couldn't be matched with a known, trusted CA.  This alert is always fatal. </del> <ins> be located or couldn't be matched with a known, trusted CA. </ins> A valid certificate or PSK was received, but when access control was applied, the sender decided not to proceed with negotiation. <del> This alert is always fatal. </del> A message could not be decoded because some field was out of the specified range or the length of the message was incorrect.  This <del> alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network). </del> <ins> alert should never be observed in communication between proper implementations, except when messages were corrupted in the network. </ins> A handshake cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message. <del> This alert is always fatal. </del> The protocol version the peer has attempted to negotiate is <del> recognized but not supported.  (For example, old protocol versions might be avoided for security reasons.)  This alert is always fatal. </del> <ins> recognized but not supported. (see backward-compatibility) </ins> Returned instead of "handshake_failure" when a negotiation has failed specifically because the server requires ciphers more <del> secure than those supported by the client.  This alert is always fatal. </del> <ins> secure than those supported by the client. </ins> An internal error unrelated to the peer or the correctness of the protocol (such as a memory allocation failure) makes it impossible <del> to continue.  This alert is always fatal. </del> <ins> to continue. </ins> Sent by a server in response to an invalid connection retry <del> attempt from a client. (see [RFC7507]) This alert is always fatal. </del> <ins> attempt from a client. (see [RFC7507]) </ins> Sent by endpoints that receive a hello message not containing an extension that is mandatory to send for the offered TLS version. <del> This message is always fatal.  [[TODO: IANA Considerations.]] </del> <ins> [[TODO: IANA Considerations.]] </ins> Sent by endpoints receiving any hello message containing an extension known to be prohibited for inclusion in the given hello message, including any extensions in a ServerHello not first <del> offered in the corresponding ClientHello.  This alert is always fatal. </del> <ins> offered in the corresponding ClientHello. </ins> Sent by servers when unable to obtain a certificate from a URL provided by the client via the "client_certificate_url" extension

Related discussion:
text: As all error alerts are now considered fatal (PR ), we no longer need "This alert is always fatal" explicitly stated everywhere in that section.
Code change:
MUST be zero. The application can specify its preferred policy regarding the use of <del> BUNDLE, the multiplexing mechanism defined in RFC8843.  Regardless of policy, the application will always try to negotiate bundle onto a single transport and will offer a single bundle group across all "m=" sections; use of this single transport is contingent upon the answerer accepting bundle.  However, by specifying a policy from the list below, the application can control exactly how aggressively it will try to bundle media streams together, which affects how it will interoperate with a non-bundle-aware endpoint.  When negotiating with a non-bundle-aware endpoint, only the streams not marked as bundle- only streams will be established. </del> <ins> BUNDLE, the multiplexing mechanism defined in I-D.ietf-mmusic- rfc8843-bis.  Regardless of policy, the application will always try to negotiate bundle onto a single transport and will offer a single bundle group across all "m=" sections; use of this single transport is contingent upon the answerer accepting bundle.  However, by specifying a policy from the list below, the application can control exactly how aggressively it will try to bundle media streams together, which affects how it will interoperate with a non-bundle- aware endpoint.  When negotiating with a non-bundle-aware endpoint, only the streams not marked as bundle-only streams will be established. </ins> The set of available policies is as follows:

Related discussion:
text: _ Roman Shpount Christer Holmberg > wrote: Hi, What about something like this: OLD: “The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP Offer in the associated 200 OK response. This is typically used for 3rd Party Call Control (3PCC) scenarios. >From a BUNDLE perspective, such SDP Offer SHOULD be generated using the procedures defined in Section 7.2.” NEW: “The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in the associated 200 OK response. This is typically used for 3rd Party Call Control (3PCC) scenarios. In some 3PCC scenarios the UAS will be part of an ongoing session, and will therefore include a subsequent offer in the 200 OK responses. The offer will be received by a 3PCC controller (UAC) and then forwarded as an initial offer to another User Agent (UA) that is currently not part of a session. When the BUNDLE mechanism is used, as an initial BUNDLE offer look different than a subsequent BUNDLE offer, it cannot be assumed that a UA that expects an initial offer will be able to properly process a subsequent offer.
Code change:
MUST be zero. The application can specify its preferred policy regarding the use of <del> BUNDLE, the multiplexing mechanism defined in RFC8843.  Regardless of policy, the application will always try to negotiate bundle onto a single transport and will offer a single bundle group across all "m=" sections; use of this single transport is contingent upon the answerer accepting bundle.  However, by specifying a policy from the list below, the application can control exactly how aggressively it will try to bundle media streams together, which affects how it will interoperate with a non-bundle-aware endpoint.  When negotiating with a non-bundle-aware endpoint, only the streams not marked as bundle- only streams will be established. </del> <ins> BUNDLE, the multiplexing mechanism defined in I-D.ietf-mmusic- rfc8843-bis.  Regardless of policy, the application will always try to negotiate bundle onto a single transport and will offer a single bundle group across all "m=" sections; use of this single transport is contingent upon the answerer accepting bundle.  However, by specifying a policy from the list below, the application can control exactly how aggressively it will try to bundle media streams together, which affects how it will interoperate with a non-bundle- aware endpoint.  When negotiating with a non-bundle-aware endpoint, only the streams not marked as bundle-only streams will be established. </ins> The set of available policies is as follows:

Related discussion:
text: Therefore, the 3PCC controller needs to act as a Back-To-Back User Agent (B2BUA), and when it receives the subsequent offer it needs to rewrite it into an initial offer before it is forwarded to such UA.” Regards, Christer From: Roman Shpount > Sent: tiistai 2. marraskuuta 2021 10.41 To: Justin Uberti > Cc: Christer Holmberg >; Justin Uberti >; RTCWeb IETF > Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-URL The PROBLEM is that we have two endpoints, where one sends a subsequent offer, and the other one expects an initial offer. What do you normally do when you have that kind of problem? You use an SBC/B2BUA. In this case that SBC/B2BUA would be the 3PCC controller. So, my suggestion would be to remove the SHOULD text from 8843bis, and simply add a note somewhere (in 8843bis and/or 8829bis) which describes the issue and says that the 3GPP controller needs to modify the offer accordingly. Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP anyway then maybe adding a=bundle-only isn't the end of the world. I am not opposed to this idea. 3PCC typically knows that the subsequent offer is going to be used as initial, and should be able to rewrite the offer to make it valid. We can change SIP Considerations section in 8843bis (URL), remove the SHOULD, and specify that 3PCC controller should fix the offer. We can then reference this note from 8829bis or restate the same guidance. Roman Shpount
Not seeing any objections for a month then once -02 is submitted we will progress this towards our AD. spt
Code change:
parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned. <del> If the description is of type "offer", and the ICE ufrag or password changed from the previous remote description, as described in Section 9.1.1.1 of RFC5245, mark that an ICE restart is needed. </del> <ins> If the ICE ufrag or password changed from the previous remote description, then an ICE restart is needed, as described in Section 9.1.1.1 of RFC5245 If the description is of type "offer", mark that an ICE restart is needed.  If the description is of type "answer" and the current local description is also an ICE restart, then signal the ICE agent to begin checks as described in Section 9.3.1.1 of RFC5245.  An answer MUST change the ufrag and password in an answer if and only if ICE is restarting, as described in Section 9.2.1.1 of RFC5245. </ins> Configure the ICE components associated with this media section to use the supplied ICE remote ufrag and password for their

Related discussion:
text: But now we need to go back to the drawing board with trickling end-of-candidates. If the ufrag needs to be trickled, we can't just trickle a "null" candidate. And we can't trickle a single special candidate with a ufrag, because different media descriptions could have different ufrags.
:-/ Perhaps we could generate individual end-of-candidates objects, followed by a null for backcompat. The null would serve as an implicit end-of-candidates for the current ufrag, but new apps would never use the null.
I think I lean towards having the trickle candidates strongly tied to a ufrag/pwd.
To provide an update on this issue: I think we still want to clarify that if there's a pending ICE restart initiated by the remote peer, any remote candidates from the new "ICE negotiation session" should be queued and only processed by the local ICE agent once the stable signaling state is reached. I don't think this can go in the trickle ICE spec, because trickle ICE has no concept of a pending ICE restart (it's a consequence of having the ability to roll back an ICE restart offer). Also, last I heard the decision was to trickle the ufrag and mid along with end-of-candidates indications. So the second paragraph of the section will need to be changed to reflect this; it's no longer one indication "for all media descriptions in the last remote description".
I've dealt with the second paragraph in PR . The first seems mostly like a "can't happen" to me. As an offerer, you should not be receiving candidates before the answer (that indicates a signaling channel reordering issue). I suppose in principle as an answerer you could receive ice candidates while thinking about the offer, but I think that the answer there is you just discard them.
See also
Code change:
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.

Related discussion:
text: moves quota-policies from RateLimit-Limit -> RateLimit-Policyrequires WG discussion -
Given this hint from Mark URL I think it's fine to merge this PR (separate Policy from Limit) since there seems to be agreement to use different fields at least in this case.
Perhaps best to continue discussion in that issue before merging this? While the change will happen in a similar vein, we might want to wait to flesh out further details.
This seems quite arbitrary for a MUST; what is "too far in the future" and "too high"?
Agree, this is an tricky point. I think an implementation: MUST define internal threeshold of allowed values; MUST validate ratelimit fields according to those thresholds. I think we could borrow some text from Signature. See
OK, but RFC2119 language is for interoperability, and this doesn't provide any; different implementations (or deployments) are going to have different values, and that may cause issues. It'd be better to defines precise limits if you think this is important enough to merit a MUST. Personally, I'd remove the 2119 language and just give guidelines about what implementations should consider when they're looking for abuse.
Ok, great!
Addressed in
The draft today suggests putting quota policies, a list, into the header. But that's a sort of breaking change, because that header's equivalent is strictly a number (not a list) in most existing implementations. Could be kept as a plain number (like and ), and instead a new header like or some such can contain supplementary information? That way, the story for upgrading to this draft is simpler. Sorry if this is asked and answered.
iirc we considered this but we initially had some requests of conflating as much as possible in fewer fields. Probably it's a more interoperable choice. I am open in re-considering the idea, provided we get in touch with the current implementers including 3scale, kong and envoy cc: 3scale: NAME , kong: NAME , envoyproxy: NAME
There's no inherent problem in using a specific header for policies, and no issue in moving to use them from the 3scale side. The only downside is we're adding yet another header for rate limiting, currently 4 of them, which might raise a few eyebrows.
Code change:
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.

Related discussion:
text: NAME thanks :) do you think that splitting is a more interoperable choice wrt to the parsing implementation / usability? Do you see other practical drawbacks? if we don't get feedback on this issue, can you ping the other implementers you know?
Yes, it's easier for people to pick up a new header for this to apply a policy, since as it stands they might break when seeing extra stuff in the limit one by expecting a single value rather than multiple, as NAME mentions above. No, just dealing with people (maybe) opposing too-many-headers - I don't know if this is something that we can predictably foresee happening in the HTTPAPI WG or in the HTTP WG, but my intuition says "likely" given how we were asked to "condense" this information, so I think we might want to spend some time making a good case out of it. NAME other than potential breakages in pre-existing implementations, is there any additional point we could make to justify the additional header? I think they are all currently listed - that being said I think porting to a new header should be an easy task, so hopefully not a problem.
if almost everyone is implementing just the minimal specification, probably this could even simplify the addition of ...
The primary motivation is breakage, as you suggest, NAME The secondary motivation is ease of "upgrading" to adoption of quota policies, as NAME suggests. The flipside of "easy to adopt, easy to upgrade" is that the spec would also make it easy to never upgrade at all. This is a good thing, supposing that most services can operate perfectly fine without quota policies. A third, much weaker argument, is that the current approach of putting the "limit" and "quota policy" in the same header is that it's confusing. I would need more time to really state this argument more clearly, but what rubs me the wrong way here is that the current design basically puts two different kinds of data in the same list. As it stands, is a list of a numbers, but the first number (the "limit") is not like the rest of the numbers (the policy). The first number cannot have SFV parameters, but the others can (and typically will). It's an accident of SFV's syntax that this is even conceivable as an approach.
Code change:
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.

Related discussion:
text: For implementors, this means that does not simply deserialize as some sort of . It deserializes into a list, where the first element is an and the tail is a . I fear this will at minimum confuse folks, and perhaps even lead to incorrect implementations, such as people not realizing the first element of the list is not a quota policy at all.
Given URL it seems there's some consensus in providing quota policy in a separate field.