jiebi/CodeConvo huggingface dataset:
Change:
either key config specifies a KEM, KDF, or AEAD algorithm the client doesn't recognize. <del> [OPEN ISSUE: Should the request URL encode the PA task?  This would </del> <ins> [OPEN ISSUE: Should the request URL encode the task id?  This would </ins> be necessary if we make "upload_start" an idempotent GET per issue#48.]

Discussion:
by removing the field from each of the protocol messages. Partially addresses by establishing that the task id is derived from the PA parameters for a task. We still need to specify this procedure.
On the 2021/7/7 design call we decided that the ID should be derived deterministically from the serialized PAParam by, for example, hashing it. This solves a few problems simultaneously. This settles the question of whether there should be 1:1 correspondence between a task ID and the parameters used for that task. NAME brought up an interesting question, which is how to make the task ID unique when two different data collection tasks use the same parameters. Thoughts?
The consensus here is to do SHA-256 over the PDAParams structure and use that as the 32 byte PDATaskID. However, hashing a protocol message requires us to decide on a canonical representation of a protocol message, which I think forces us to decide how to encode messages on the wire. I filed for that question. I'll proceed with a PR for this issue on the assumption that we'll pick JSON.
As I mentioned there, the assumption would be that we're adopting TLS' binary encoding. If so, in TLS notation, you would write as the hash of , which itself is a serialized data structure.
All we require is that each PAParam have some unique value, right? A random nonce would probably suffice. r.e. the encoding, yes, let's stick with TLS's wire format as NAME suggests.
Yes, my thinking was that we would just stick 16 bytes of random data in (a UUID's worth). I agree that we should stick with TLS binary encoding.
This seems unnecessary.
The PATask is always the first bit of a protocol message, and the version is the first bit of the PATask. I figured it would be helpful to version each message because messages are carried by HTTP requests. There might be a simpler/better way to do this.
I don't think we should assume that's the case. If we want to have the version not determined at the URL level (a mistake, IMO) then we should have some sort of message wrapper that contains that, rather than overloading PATask.
I'm inclined to agree with NAME we're discussing versioning the whole API in , so PATask doesn't need to also provide version information.

So, setting aside the question of message format versions, is there any value in maintaining a version on PATasks at the protocol level? I say no, because we want to be able to treat different PATasks completely independently and don't otherwise have any notion of a relationship between any two PATasks in the protocol.
Change:
When the version has been identified as QUIC version 1, the packet type needs to be verified as an Initial packet by checking that the third and fourth bit of the header are both set to 0.  Then the <del> Client Destination Connection ID needs to be extracted to calculate </del> <ins> client destination connection ID needs to be extracted to calculate </ins> the Initial Secret together with the version specific initial salt, as described in QUIC-TLS.  The length of the connection ID is indicated in the 6th byte of the header followed by the connection ID

Discussion:
We've not been capitalizing this in the main spec; so nor should this document. I've fixed those cases that I've touched in my upcoming PR, but it's going to need more work to clean up properly.
Yep, will do that after we merged the PRs. Thanks!
Change:
in attestation quality is therefore a deployment-specific task.  In Split Attester and Issuer deployments (see deploy-split), Issuers can choose to remove compromised Attesters from their trusted set until <del> the compromise is patched, without needing to modify Origin allow- lists. </del> <ins> the compromise is patched. </ins> 3.2.2.

Discussion:
cc NAME
[x] 1. The Reference PPEXT is not cited in the document. seems it could be sited in the into PR [x] 2. I think it would be good to explicitly say that the HTTP authentication protocol is targeted at redemption and the issuer protocol is targeted at issuance. PR [ ] 3. Last paragraph in section 3.2.1 mentions Origin Allow Lists. These allow lists are not specifically mentioned earlier in the document. Can you clarify this. [ ] 4. In section 4.3 and 4.4 is the attester involved in the TokeRequest and TokenResponse messages? Is the attester proxying the communication? It would be good to clarify this in the text. [ ] 5. Section 6 has an incomplete reference. [x] 6. It seems that the Reference to RFC 8446 is not needed. PR [ ] 7. The link - URL does not work perhaps this is the updated one? - URL
Change:
They can load the bundle's metadata given a prefix of the bundle. They can find a representation within the bundle given that <del> representation's URL (semantics-naming) and the content- negotiation information that would appear in an HTTP request's headers. </del> <ins> representation's URL (semantics-naming). </ins> 2.2.

Discussion:
This PR removes content negotiation from the spec. It is more efficient to use content negotiation on the server to select which bundle to send, rather than including several variants in the bundle and having that negotiation happen on the client's side. Issue: URL Adapted from URL
Now that the working group has adopted the document, we actually need them to approve significant changes like this one, not me. We can check on this one during the IETF meeting .
Moved from NAME URL It's more efficient to use content negotiation to select which bundle to serve, rather than including several variants of a resource inside a bundle. Even most use cases around re-sharing bundles while offline can get away with including a single least-common-denominator resource. I only know of the case of translations that concretely need several variants of the same resource. Can we simplify the design by omitting content negotiation? We'd lose some fidelity in representing HTTP, but that might be acceptable.
I"m fine to remove the variants support from the bundle format, however, I'm wondering how removing the variants support impacts on the chromium's implementation. We should align somehow. NAME NAME Do you know any use case of variants? Can we remove variants support from the bundle format without any impacts on the chromium?
Chromium supports variants in Navigation to Web Bundles (URL), but not in Subresource loading with Web Bundles. Since Navigation to Web Bundles hasn't shipped yet, I think it's fine to remove it from Chromium.
If we remove the content negotiation, it may become difficult to support new data formats like WebP in future. But removing it from the bundle format now and re-thinking when it will be more important sounds acceptable.
The idea here is that you would negotiate for the whole bundle, not for resources within the bundle. I think this could permit upgrade to new image formats over time, without shipping all the different options redundantly to the client.
I think we can close this issue. Content negotiation was already dropped.
Thanks for making a PR! Per the discussion URL, the chromium side is okay to remove content negotiation. We probably have to change parser's behavior by checking a bundle's version. That should not be a significant issue for us. We might want to wait for NAME 's approval before merge.
Change:
as their corresponding messages sent in other flights (handshake, application_data, and alert respectively) but are protected under different keys.  After receiving the server's Finished message, if <del> the server has accepted early data, an "end_of_early_data" alert of type "warning" MUST be sent to indicate the key change.  This message will be encrypted with the 0-RTT traffic keys. </del> <ins> the server has accepted early data, an EndOfEarlyData message will be sent to indicate the key change.  This message will be encrypted with the 0-RTT traffic keys. </ins> A server which receives an "early_data" extension can behave in one of three ways:

Discussion:
key changes happen at Handshake boundaries. Suggested by David Benjamin
I have one here, that could be a start: URL Also this is assuming PR URL is accepted ( becomes a message)
Merged.
Change:
all, it will ignore it as required by Section 4.1.2 of RFC8446. Provided the server can present a certificate valid for the public name, the client can safely retry with updated settings, as described <del> in handle-server-response. </del> <ins> in rejected-ech. </ins> Unless ECH is disabled as a result of successfully establishing a connection to the public name, the client MUST NOT fall back to using

Discussion:
Handling server response discusses how to dispatch between accept/reject, but the retry flow is specifically the reject bit.
Change:
identical.  This assists development and debugging by making it easier to understand individual media sections, especially if one of a set of initially identical attributes is subsequently changed. <ins> However, implementations MAY choose to aggregate attributes at the session level and JSEP implementations MUST be prepared to receive attributes in either location. </ins> Attributes other than the ones specified above MAY be included, except for the following attributes which are specifically

Discussion:
I did add a MUST here, but I think it's just a restatement of what is already true.
BLOCKER: Several of the SDP-building procedures in this document call out addition of "a=fingerprint" to individual media sections, while the canonical definition of "a=fingerprint" allows these to be added at either the session level or the media level. The same is true of ice-pwd and ice-ufrag. While the process of SDP building in this document appears to be prescriptive on purpose, one assumes that it is allowed some variation so as to accommodate deployment of future SDP extensions. Because of this state of affairs, it is unclear whether implementations that consolidate these attributes at the session level when they would otherwise be identical among all media sections is such an allowable variation. Ambiguity in specifications is never a good thing, so I believe that the draft needs to do one of: (a) specifically call out this kind of aggregation as allowed; (b) specifically call out this kind of aggregation as disallowed; or (c) include a blanket statement that implementations are allowed to emit SDP that is semantically equivalent to that which is generated by the procedures in this document, but which may vary in exact structure. I have a strong preference for (c) -- implementations will be required to deal with such variations anyway to interop with legacy SDP, so prohibiting JSEP clients from generating them serves no goal.
My suggestion would be to expand the para below to say (a), i.e. that applications that wish to aggregate may do so, even though we recommend not aggregating. Attributes which SDP permits to either be at the session level or the media level SHOULD generally be at the media level even if they are identical. This promotes readability, especially if one of a set of initially identical attributes is subsequently changed.
(and also fine with suggestions Justin is suggesting)
Change:
balancers to apply the correct routing algorithm and parameters to incoming packets. <del> Configuration Agents SHOULD make an effort to deliver new configurations to load balancers before doing so to servers, so that load balancers are ready to process CIDs using the new parameters when they arrive. </del> <ins> Configuration Agents SHOULD deliver new configurations to load balancers before doing so to servers, so that load balancers are ready to process CIDs using the new parameters when they arrive. </ins> A Configuration Agent SHOULD NOT use a codepoint to represent a new configuration until it takes precautions to make sure that all

Discussion:
Erik Fuller points out via email: He's right. We should just call it a configuration ID and be clearer on what's what.
Change:
options are entirely orthogonal: the server independently selects a cipher suite, an (EC)DHE group and key share for key establishment, and a signature algorithm/certificate pair to authenticate itself to <del> the client.  If any of these parameters has no overlap between the client and server parameters, then the handshake will fail.  If there is overlap in the "supported_group" extension but the client did not offer a compatible "key_share" extension, then the server will respond with a HelloRetryRequest (hello-retry-request) message. </del> <ins> the client.  If there is overlap in the "supported_group" extension but the client did not offer a compatible "key_share" extension, then the server will respond with a HelloRetryRequest (hello-retry- request) message. </ins> If the server selects a PSK, then the PSK will indicate which key establishment modes it can be used with (PSK alone or with (EC)DHE)

Discussion:
I took this bit out of the 1st paragraph: -If any of these parameters has no overlap between the -client and server parameters, then the handshake -will fail. and moved it to the last para in the section because it doesn't say what alert value is to be returned, there's not something similar in the following paragraph that describes the PSK failure case, and finally the full failure text is included in the final paragraph. Basically, I just move the failure case to the final paragraph. An alternate would be to copy the failure to the PSK paragraph and include the which alert to return in the non-PSK para.
Change:
were corrupted in the network). <del> This alert was used in some earlier versions of TLS, and may have permitted certain attacks against the CBC mode CBCATT.  It MUST NOT be sent by compliant implementations.  This alert is always fatal. </del> A TLSCiphertext record was received that had a length more than 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record with more than 2^14 bytes.  This alert is always fatal and should

Discussion:
Note: unRESERVEDing SHA-1 and DSA is intentional. The point is that that things which are RESERVED are totally forbidden. Because you can offer SHA-1, we need the code point. If we decide to make DSA MUSTNOT, then I'll mark it reserved and update the text.
On Saturday, October 03, 2015 04:42:44 pm ekr wrote: Agreed. Using the "RESERVED" notation before was a bit iffy and with this new refactoring it has to be changed now. Just need to make sure it's mentioned explicitly that it's restricted.
Change:
longer than needed by SRTP, then it is truncated by taking the first N bytes from the srtp_master_salt field. <ins> If the SSRC in the EKTPlaintext does not match the SSRC of the SRTP packet, then all the information from this EKTPlaintext MUST be discarded and the following steps in this list are not done. </ins> The SRTP Master Key, ROC, and SRTP Master Salt from the previous step are saved in a map indexed by the SSRC found in the EKTPlaintext and can be used for any future crypto operations on

Discussion:
This is a very substantial change. I suspect it is correct but given text in security section but think carefully about if this breaks anything.
Section 4 The presence of the SSRC in the EKTPlaintext ensures that an attacker cannot substitute an EKTCiphertext from one SRTP stream into another SRTP stream.
I think this is right.
Change:
Abstract This document describes an HTTP API that allows hosts to interact <del> with a Captive Portal system on a local network. </del> <ins> with a Captive Portal system. </ins> 1. This document describes a HyperText Transfer Protocol (HTTP) Application Program Interface (API) that allows hosts to interact <del> with a Captive Portal system on a local network.  The API defined in this document has been designed to meet the requirements in the Captive Portal Architecture I-D.larose-capport-architecture. Specifically, the API provides: </del> <ins> with a Captive Portal system.  The API defined in this document has been designed to meet the requirements in the Captive Portal Architecture I-D.ietf-capport-architecture.  Specifically, the API provides: </ins> The state of captivity (whether or not the host has access to the Internet)

Discussion:
Removed language for /.well-known URI. Made serving over port 443 a SHOULD requirement. Other editorial changes
Added your updated language, should be good to go.
I don't think that we need this. 7710 gives us an entire URI, as can PvD.
I agree that we can use the URI from the DHCP option or from PvD. The reason I went this route was to avoid the scheme that was in the API draft to start with, which seemed to be: If you access the 7710 URI with a GET, you'll receive the HTTP for the user interactive portal If you access the 7710 URI with a POST, you'll get the JSON API That seemed problematic (a) because it implies the user portal and API are co-located and (b) it seemed overly complex. Do you have a preference for what methods are valid to access the JSON API, and whether we should specify that the URI needs to be JSON? My concern was that if the DHCP option or whatever pointed to something that was clearly .html, something's wrong, and using a well-known JSON URI to compare against would be a way to detect that.
NAME Thoughts on the method for fetching the JSON API, or if that's a non-issue?
Let's take this to the list.
PR fixes the well-known URI language. For now there is indication of Accept and Conent-Type header usage but we haven't explicitly called it out until we get a final decision. We can close this issue though.
Change:
payload type of the primary codec, as specified in RFC4588, Section 8.1. <del> For each supported FEC mechanism, a corresponding "a=rtpmap" line indicating the desired FEC codec. </del> <ins> For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6.  The FEC mechanisms that MUST be supported are specified in I-D.ietf-rtcweb-fec, Section 6, and specific usage for each media type is outlined in Sections 4 and 5. </ins> "a=ice-ufrag" and "a=ice-passwd" lines, as specified in RFC5245, Section 15.4.

Discussion:
This looks basically good. I see one missing reference and some places where I think the text might read better. Feel free to ignore my advice on the text, but you should probably fix the reference
PTAL
LGTM
Depends on resolution of FEC on mailing list
This will be dealt with in a future rev.
Justin, where are we here? Should I unmark this discuss?
Unmark as discuss since we need a proposal to discuss first (which I have the action for)
Action to write draft here listing FEC mechanisms that are MTI
Draft completed; now we just need JSEP to refer to uberti-rtcweb-fec.
Change:
10.1.  URIs <del> [1] https://github.com/abetterinternet/prio-documents/issues/102 </del> <ins> [1] https://github.com/abetterinternet/ppm-specification/issues/102 </ins> <del> [2] https://github.com/abetterinternet/prio-documents/issues/22 </del> <ins> [2] https://github.com/abetterinternet/ppm-specification/issues/22 </ins>

Discussion:
The repo was renamed to "ppm-specification". This commit replaces various occurences of the old repo's name, and also updated URL to reflect the current name of the protocol.
Change:
The transport protocol described by this document.  QUIC is a name, not an acronym. <del> A complete processable unit of QUIC that can be encapsulated in a UDP datagram.  Multiple QUIC packets can be encapsulated in a single UDP datagram. A QUIC packet that contains frames other than ACK, PADDING, and CONNECTION_CLOSE.  These cause a recipient to send an acknowledgment; see sending-acknowledgements. </del> An entity that can participate in a QUIC connection by generating, receiving, and processing QUIC packets.  There are only two types of endpoint in QUIC: client and server.

Discussion:
I struggled with this a little. Happy to take suggestions.
I'm going to say that the IP Packet vs. QUIC Packet text is not necessary. We carefully qualify where there is any potential for confusion.
On the other issue, it might be worth simply stating the terminology upfront. Something like


Datagram Size There is some confusion in the text between packets, frames and datagrams. That could be helped by earlier clarification.
This is a duplicate of .
12.4. Frames and Frame Types Packet Payload { Frame (8..) ..., } Version Negotiation, Stateless Reset, and Retry packets do not contain frames. At this point (page 82) I am still not sure what a packet or a frame is and have no idea what is going on on the wire.
Probably a duplicate of . These terms should be added to the definitions, with possibly some additional explanatory text in Section 12.
Section 1 is the first place that you introduce the term "Frame". I got very confused about frames and packets, and I thing the taxonomy needs to be clearly explained. You have UDP/IP packets that carry one or more QUIC PDUs, but the frame/packet notation made it unclear what was being discussed and whether the terms were being used consistently. Some clarification would be useful, or if it is in the text then making it more obvious would help.
Perhaps "frame" and "datagram" should be added as defined terms in Section 1.2. On a related note, the defined term is "QUIC packet" but in the text we don't always specify what type of "packet." Perhaps we should define "packet" as generally referring to QUIC, with a note that IP packets will be indicated as such. (I believe all instances of "packet" that refer to IP explicitly say "IP packet," but we should verify that.)
One small suggestion, which you can ignore if you don't like it.
Change:
Capsules MUST be forwarded unmodified by intermediaries, with the exception of the DATAGRAM capsule; see datagram-capsule.  An <del> intermediary that understands the request semantics enough to know that capsules are in use MAY convert between QUIC DATAGRAM frames and DATAGRAM capsules.  Definitions of new Capsule Types MAY specify optional custom intermediary processing. </del> <ins> intermediary can identify the use of the capsule protocol either through the presence of the Capsule-Protocol header field (hdr) or by understanding the chosen HTTP Upgrade token.  An intermediary that identifies the use of the capsule protocol MAY convert between DATAGRAM capsules and QUIC DATAGRAM frames when forwarding. Definitions of new Capsule Types MAY specify optional custom intermediary processing. </ins> Endpoints which receive a Capsule with an unknown Capsule Type MUST silently drop that Capsule.

Discussion:
cc NAME
I think that this is right, but we should be more precise about what this means. That is, if the method is CONNECT and either: the intermediary understands the :protocol selection, or the request includes Capsule-Protocol Then the intermediary can forward DATAGRAM capsules as QUIC DATAGRAM frames or forward QUIC DATAGRAM frames as DATAGRAM capsules. Those conditions could be spelled out more clearly.
I agree. I'll add this to the . Note that this was filed on the wrong repository, is the droid you're looking for.
Oops. You should be able to move the issue.
Ah right, thanks! I've moved the issue.