jiebi/CodeConvo huggingface dataset:
Change:
6. <ins> This specification provides a formal definition of the syntax of Content-Format-Spec strings using ABNF notation RFC5234, which contains three new rules and a number of rules collected and adapted from various RFCs RFC7231 RFC6838 RFC5234 RFC8866. 7. </ins> The indication of a media type in the data does not exempt a consuming application from properly checking its inputs.  Also, the ability for an attacker to supply crafted SenML data that specify

Discussion:
Alexey notes (Archived-At: ): Since data-ct needs almost all of the “normative” ABNF in media-content-type-format, I think the right thing to do would be to fully develop media-content-type-format and make it a normative reference. (Note that media-content-type-format probably needs to be run by httpbis and emailcore [?] soon and when it is nearing WGLC, and there may be surprises there.) This course of action would probably delay data-ct a bit; we might counteract the damage by early registration. Since data-ct only needs an “Expert Review” registration, we could decide to do this when we have processed the reviews that are now incoming.
I didn't do thorough review of the ABNF but otherwise looks good to me Hi all, Sorry for the belated review. I think the document is nearly ready for progression. I have a couple of minor related issues: Terminology Readers should also be familiar with the terms and concepts discussed in [RFC8428]. Awareness of terminology issues discussed in [I-D.bormann-core-media-content-type-format] can also be very It is expired and it is currently not a WG document. At minimum it should be revived. (Or see below) helpful. SenML Content-Format ("ct") Field I wish the document has ABNF for the "ct" field. If you want to use ABNF from draft-bormann-core-media-content-type-format-01, it should be Normative reference. If not, I think you should just cut & paste the ABNF into this document. Best Regards, Alexey
Change:
algorithm only if the "signature_algorithms" extension provided by the client permits it.  If the client cannot construct an acceptable chain using the provided certificates and decides to abort the <del> handshake, then it MUST abort the handshake with an "unsupported_certificate" alert. </del> <ins> handshake, then it MUST abort the handshake with an appropriate certificate-related alert (by default, "unsupported_certificate"; see error-alerts for more). </ins> If the server has multiple certificates, it chooses one of them based on the above-mentioned criteria (in addition to other criteria, such

Discussion:
There are a number of different alerts that may be suitable for sending to indicate a non-acceptable cert chain, e.g. certificaterevoked, certificateexpired, unknown_ca, etc. We should not restrict the client to only sending one specific alert.
I have updated this PR with the wording as suggested by NAME
Change:
present in the remote offer, as specified in RFC3264, Section 6.  For the purposes of this discussion, any session-level attributes in the offer that are also valid as media-level attributes are considered to <del> be present in each m= section. The next step is to go through each offered m= section.  Each offered m= section will have an associated RtpTransceiver, as described in sec.applying-a-remote-desc.  If there are more RtpTransceivers than there are m= sections, the unmatched RtpTransceivers will need to be associated in a subsequent offer. </del> <ins> be present in each m= section.  Each offered m= section will have an associated RtpTransceiver, as described in sec.applying-a-remote- desc.  If there are more RtpTransceivers than there are m= sections, the unmatched RtpTransceivers will need to be associated in a subsequent offer. </ins> For each offered m= section, if any of the following conditions are true, the corresponding m= section in the answer MUST be marked as

Discussion:
There are two paragraphs on page 50 that start "The next step is to". They are both referring to the same step. I suggest combining the paragraphs.
I think I would just change the second one to "Finally"
LGTM
Change:
10118-3, ISO-IEC-14888-3, ISO-IEC-15946-1, ISO-IEC-18033-3, IEEE-Std- 1363-2000, IEEE-Std-1363a-2004, NIST-PUB-FIPS-202, NIST-SP800-38C, NIST-SP800-38D, NIST-SP800-38F, NIST-SP800-56A, NIST-SP800-108, bios- <del> log, ima-log, and netequip-boot-log exist within the YANG Model. </del> <ins> log, ima-log, as well as ima and netequip-boot-log exist within the YANG Model. </ins> 2.1.2.1.

Discussion:
Self-approved
Thanks, this does a good job bridging the gap between what we say in the body of the document and what is available in external references.
Change:
Calling this method may do things such as generating new ICE credentials, but does not trigger candidate gathering or cause a media state change.  Specifically, the answer is not applied, and <del> does not become the pending local description, until </del> <ins> does not become the current local description, until </ins> setLocalDescription is called. 4.1.8.

Discussion:
In 4.1.7 (create Answer) why would calling setLocalDescription cause the answer to be a pending local description. I think it's the full on local description at that point, not a pending one?
Yes, this is an error in the text.
LGTM
Change:
ClientHello, MUST contain the ConnectionId structure, which carries the CID which the client wishes the server to use when sending messages towards it.  A zero-length value indicates that the client <del> is prepared to send with a connection ID but does not wish the server to use one when sending (alternately, this can be interpreted as the client wishes the server to use a zero-length CID; the result is the same). A server which is willing to use CIDs will respond with its own "connection_id" extension, containing the CID it wishes the client to use when sending messages towards it.  A zero-length value indicates that the server will send with the client's CID but does not wish the client to use a CID (or again, alternately, to use a zero-length CID). </del> <ins> is prepared to send with a CID but does not wish the server to use one when sending (alternately, this can be interpreted as the client wishes the server to use a zero-length CID; the result is the same). A server willing to use CIDs will respond with a "connection_id" extension in the ServerHello, containing the CID it wishes the client to use when sending messages towards it.  A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID (or again, alternately, to use a zero-length CID). </ins> When a session is resumed, the "connection_id" extension is negotiated afresh, not retained from previous connections in the

Discussion:
It probably makes sense to be a little more consistent.
Makes sense. I will do this after the current wave of pull requests have been reviewed and accepted/rejected.
I addressed this issue in PR
Addressed with submitted draft version -04
I don't think that you need to change the grammar.
Change:
media formats MUST be generated in the corresponding order, and MUST exclude any codecs not present in the codec preferences. <ins> The media formats in the answer MAY include codecs present in the offer that were discarded in a previous offer/answer exchange. This is necessary for compatibility with third- party call control and SIP use cases. </ins> Unless excluded by the above restrictions, the media formats MUST include the mandatory audio/video codecs as specified in I-D.ietf- rtcweb-audio(see Section 3) and I-D.ietf-rtcweb-video(see

Discussion:
Fixes issue .
Note that I made this a MAY and not a MUST, because the only precedent for a MUST in codec selection is with regards to the mandatory codecs.
This seems like it still needs some more work, as we discussed earlier.
I added some more informative text about non-JSEP endpoints. Does this address your concerns Ekr? There are still some questions about when (if ever) a JSEP endpoint is allowed to include previously discarded codecs in an offer (issue ), but this PR should at least address issue .
Browser offer MCU, VP9, and VP10. MCU answers with VP10. Offer / answer completes. Later the MCU offers VP9 to browser on m-line that was currently use VP10. What does the browser do? A strict reading of spec might suggest that since MCU only offered VP9, and current is VP10, the m-line should be rejected. Do we need to change this ? Is it OK for browser to respond with VP9.
Previously I've heard people say "the non-JSEP endpoint can do whatever it wants with codecs." For example, in the thread for issue .
It is definitely OK for the browser to accept the VP9 in the updated offer and I would go further and say that it must accept VP9 in such an updated offer if it is capable of doing so. The spec should make it clear that browsers MUST accept such codec changes in updated offers.
If we solve this, should resolve.
Originally raised by Magnus. If any payload type could map to more than one RtpReceiver, map to the RtpReceiver whose m= section appears earliest in the local description. I think this is a bad advice. I think it should say that if this is the case, PT should not be used to try to determine which m= section it belongs to. I think wrongly attributing a packet is worse than dropping it in cases where the information is incomplete. This rule can result in that one associate an SSRC with the wrong m= section.
there is another bug on this too - I agree we could change this
Obsoleted by events - moved to BUNDLE
With changes above
Change:
that the load balancer will redirect the next Client Initial packet to a different server in that pool. <del> 9. </del> <ins> 10. </ins> Versioning in QUIC may change the protocol's behavior completely, except for the meaning of a few header fields that have been declared

Discussion:
addresses issue
I think the applicability draft may benefit from exploring connection migration strategies as described in: URL
Do we also need to say anything about use of 0-byte CID? See quicwg/base-drafts
The transport draft already says:
addressed by PR and one more sentence
I don’t see any text related to connection migration on that PR.
sorry wrong PR; should be and is already merged
good modulo typos
Change:
body, the verifier MUST decode the payload of the JWS object and treat this as the HTTP message body. <ins> Note that this proof method depends on a specific cryptographic algorithm, SHA-256, in two ways: the "ath" hash algorithm is hardcoded, and computing the payload of the detached/attached signature also uses a hardcoded hash.  A future version of this document may address crypto-agility for both these uses by replacing ath with a new header that upgrades the algorithm, and possibly defining a new header that indicates the HTTP content's hash method. </ins> 8. GNAP provides a rich structure for describing the protected resources

Discussion:
To edit notification comments on pull requests, go to your ._
There have been several questions about the parameter currently used to convey the hash of an access token in requests to the RS. Right now we use the definition from OpenID Connect: URL In speaking with the DPoP editors I've proposed a simplified claim there: URL It's functionally similar but doesn't require the array truncation step, and it also fixes to a single hash algorithm (SHA-256) instead of having to figure out which hash to use based on the external signing envelope. I think this change makes it both simpler to implement and to understand.
Also, for cryptographic agility here we would rely on defining a new claim name and updating the requirements about inclusion. So would always be SHA-256 and once that hash is sufficiently broken and discarded we would define a new claim like for whatever new target there is.
+1 for that, much more intuitive than truncating (and the comment from DPoP editors seem to go in that direction too). In relation to what would happen if SHA-256 gets deprecated: the current method is already based on SHA-256, so it's not a new downside an idea would be to name it for instance, to give a minimal versioning (would currently relate to SHA2) and would simplify changes later on (like avoiding ;-))
I personally think that naming the next version of the field should be left to the next version. Someone might want to specify or even , but the important thing is that we aren't defining plus parameters, we're just defining and anything else comes along as its own unique string. That kind of guidance can be written around the registry for the claim and how it'd get used.
works too
Reopening this issue: we are not providing cryto-agility, because: We do not indicate how the algorithm could change. Renaming the field to would remedy that. An implementation that did not include would formally be non-compliant, because the field is REQUIRED. We should say something about that. See URL
NAME crypto agility would be provided by defining a new field entirely. The algorithm will not change for . This was discussed in the OAuth WG with DPoP's field which has the same semantics as this. I do not recommend we re-open this.
I'm not asking to reopen it. Just to add a note in the text. The IESG reviewers are bound to comment on this.
Change:
Special thanks go to Joerg Borchert, Nancy Cam-Winget, Jessica Fitzgerald-McKay, Thomas Fossati, Diego Lopez, Laurence Lundblade, <del> Wei Pan, Paul Rowe, Hannes Tschofenig, Frank Xia, and David Wooten. </del> <ins> Paul Rowe, Hannes Tschofenig, Frank Xia, and David Wooten. </ins> 15.

Discussion:
Wei Pan was added to the author list but wasn't removed from the Acknowledgements section at the time so now appears in both places. This PR corrects that. Signed-off-by: Dave Thaler
Yeah. I think this is yet another artifact and Dave is absolutely right here. Wei is already an "acknowledged editor" and therefore obviously does not has to be included in a potential ack section, apparently.
Thanks for your careful observation.
Change:
WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. <del> From the client's perspective, a WebTransport session is established when the client receives a 200 response.  From the server's perspective, a session is established once it sends a 200 response. Both endpoints MUST NOT send any WebTransport capsules on a given session before that session is established. </del> <ins> A WebTransport session is established when the server sends a 200 response.  A server generates that response from the request header, not from the contents of the request.  To enable clients to resend data when attempting to re-establish a session that was rejected by a server, a server MUST NOT process any capsules on the request stream unless it accepts the WebTransport session. A client MAY optimistically send any WebTransport capsules associated with a CONNECT request, without waiting for a response, to the extent allowed by flow control.  This can reduce latency for data sent by a client at the start of a WebTransport session.  For example, a client might choose to send datagrams or flow control updates before receiving any response from the server. </ins> 3.4.

Discussion:
I don’t agree with this. A client can send a request body without awaiting a response. Always. Originally posted by NAME in URL
Are those concerns orthogonal? I don't believe there is anything in the text that says you cannot send data before the session is established.
I don't think that this is necessary, or helpful. And I don't think that you can police it either. It is true that a client cannot initiate any streams before the session is created (because the stream limits start at zero), but I see no reason not to pipeline WTDATAGRAM or MAX frames if the h2-level flow control permits it. The MAX_ frames are particularly useful in that they allow the server to send real data immediately, cutting a round trip off.
Given that the limits start at zero (do we state that explicitly anywhere?), and we're not including any sort of SETTINGS/default settings, it definitely seems like we ought to be able to just start spewing frames into the CONNECT stream, which are discarded if the CONNECT request is rejected.
Chair: discussed at 113, consensus in room to allow sending any frames allowed by flow control
Text in H3 here: URL, can probably make it look similar for H2.
Change:
8.3. <del> Attestation Results may indicate compliance or non-compliance with a Verifier's Appraisal Policy.  A result that indicates non-compliance can be used by an Attester (in the passport model) or a Relying Party (in the background-check model) to indicate that the Attester should not be treated as authorized and may be in need of remediation.  In some cases, it may even indicate that the Evidence itself cannot be authenticated as being correct. </del> <ins> Attestation Results are the input used by the Relying Party to decide the extent to which it will trust a particular Attester, and allow it to access some data or perform some operation.  Attestation Results may be a Boolean simply indicating compliance or non-compliance with a Verifier's Appraisal Policy, or a rich set of Claims about the Attester, against which the Relying Party applies its Appraisal Policy for Attestation Results. A result that indicates non-compliance can be used by an Attester (in the passport model) or a Relying Party (in the background-check model) to indicate that the Attester should not be treated as authorized and may be in need of remediation.  In some cases, it may even indicate that the Evidence itself cannot be authenticated as being correct. </ins> An Attestation Result that indicates compliance can be used by a Relying Party to make authorization decisions based on the Relying

Discussion:
Address issue
Attestation Result is far more than compliance/non-compliance for many / most use cases. Attestation Results may contain lots claims that are passed through from the device (e.g., GPS location). I would also expect information from the Endorsement to be passed through, particularly in the case where the Verifier is an aggregator. Implied claims would also show up in the Attestation Result.
Section 7.3 starts out "Attestation Results may indicate compliance or non-compliance with a Verifier's Appraisal Policy" implying binary yes/no results. Section 7.3 needs to get rewritten some so results can be very rich with dozens of claims that are input to the RP's risk engine.
The -05 draft with Attestation Results moved to section 8.3 still has too much emphasis on compliance/non-compliance.
Change:
Domain (optional).  Used for domain, group, endpoint and resource lookups. <del> resource (optional).  Used for domain, group, endpoint and resource lookups. </del> gp := Group name (optional).  Used for endpoint, group and resource lookups.

Discussion:
This solves issue ("nobody really knows what the parameter is for") by removing the parameter altogether.
We are not clear on how to use "res"in a lookup query. For example, what does xx represent in this query? GET /example/rd-lookup-gp?res=xx I couldn't find text to explain. Is it expected to be the address of a resource, like href or anchor+href ?
Hi Michael, From version 04 to the current version the ?res has undergone a change In the -10 example the return is ;rt=sensor;ct=60 where I might have expected ;rt=sensor;ct=60 But I cannot check because we do not know the contents of the RD and hypothesizing now: ?res=xx would have returned nothing unless there was an entry like ;rt=sensor;ct=60 and even more confusing we have something called resource-param. In an earlier e-mail Christian already suggested to modify that to link-param if I remember correctly. So yes, I can concur with you and agreeing with the existence of confusion. Peter Michael Koster schreef op 2017-05-05 16:01:
The last I had in mind about the parameter a short mention in the phone call -- to me it looked like a relic whose role has been superseded by ins et al. It is now the first time I perceive it as a parameter that does anything with the path. What is the intended overall purpose of res=? And what do you mean by the contents of the RD?
Hi Chris, I assume this a sequel to my answer to Michael. May be not..... The contents of the RD are all the information about ep, resources, etc. stored into the RD by whatever means. My speculation about res=xx means that it indicates filtering on resource paths which start with /xx/...... Peter
For such filtering, there is already , which is covered by the query parameter referencing RFC 6690. NAME of the RD": I see. Going through all the references in the document, it seems to me that the examples you mentioned are not about the lookup parameter, but just the arbitrary resource names in the pagination example. I'd suggest removing the parameter altogether (PR ) unless its use resurfaces.

I think "res" (for resource) may be useful as a link target attribute for tagging resources, and in that context could also be used as a lookup parameter. If we don't plan to create "res" as a target attribute we should remove it from the document. If we do want to define a new target attribute, maybe we can come up with something more descriptive than "res"...
Change:
The JWK representation of the new key The client then encapsulates the key-change object in a JWS, signed <del> with the client's current account key (i.e., the key matching the "oldKey" value). This inner JWS then become the payload of the JWS that the client sends to the server.  The outer JWS is signed with the key pair that the the client wishes to have the server use as its account key (i.e., the key pair matching the "newKey" value).  The client sends this outer JWS in a POST request to the server's "key-change" resource. </del> <ins> with the requested new account key (i.e., the key matching the "newKey" value). </ins> The outer JWS MUST meet the normal requirements for an ACME JWS (see request-authentication).  The inner JWS MUST meet the normal

Discussion:
Signing with the current account key allows servers to use the same message transport authentication that they use for other requests, simplifying the verification. Also fix two spots where we still described newKey/oldKey as thumbprints.
LGTM. I had only done that signing order to be forward-compatible with some imagined future recovery scheme, but if we decide to do that someday, that patch can differ in signature order as well as whatever else.