jiebi/CodeConvo huggingface dataset:
Change:
Clients can use padding to reduce the effectiveness of traffic analysis.  Padding is a capability provided by binary HTTP messages; <del> see BINARY. </del> <ins> see BINARY.  If the encapsulation method described in this document is used to protect a different message type (see repurposing), that message format might need to include padding support. </ins> 6.3.

Discussion:
This is a lot more disruptive, but I think it is a clearer description of how you might repurpose this design. I'm still a little unsure about using application/dns-message, but I can live with it.
If this is acceptable, I might cherry-pick some of the other changes from rather than take it wholesale.
OK, I think that I understand what you are looking for and I agree, we can say more about that. But we probably don't need to say heaps more. Is the latest commit what you are looking for?
NAME I think it's closer, but I genuinely don't see why noting precisely where things need to change in the spec is harmful. I prefer Tommy's original change here.
Yeah, this still doesn't solve the problem of letting implementers know which parts of the encapsulated request processing are the bits that can become generic to handle other media types. Another way to look at this is, for another spec to define how to use another media type, it should be easy to simply say "the OHTTP spec explains the couple places where the media type can be changed from BHTTP to something else — and this use of OHTTP tells you to use a different media type in those spots". We should avoid having new specs like this need to wholesale copy the sections of the OHTTP document that define how to use HPKE, etc, and just have one subtle difference.
I'm not seeing that. I realize that I missed the padding piece (though I don't consider that particularly important, it's worth mentioning). For a generic format, the only adaptation required is replacing the constant strings. This describes how that might work. That we don't burden the reader of the algorithm piece with this detail at the time is a feature, not a bug, as far as I'm concerned.
I don't consider it a burden. I think it's an important piece for someone who's implementing OHTTP since it has API implications. For example, one could implement the main encap and decap algorithms using the fixed "message/bhttp" content type and then find they have to either duplicate code later on adjust their encap and decap APIs (or something else) to accommodate another type of application encoding.

The inline hints from the original suggestion in suggest that implementers might want to allow for changes to the content type string so they don't run into this situation down the road, and they're minimally invasive hints at that.
I've added the pointers, as requested. (I only skipped one on the decapsulation process as that seemed redundant.)
Thanks, latest changes look good to me
Change:
2.10.1. Individual OTSi protection is a protection architecture where an <del> individual OTSi signal is protected as defined in Appendix III of </del> <ins> individual OTSi signal is protected as described in Appendix III of </ins> ITU-T Recommendation G.873.1 G.873.1.  This protection architecture <del> requires dedicated photonic protection functions that are typically provided by dedicated protection hardware.  These photonic protection functions are a photonic splitter function splitting the OTSi signal in transmit direction and a photonic selector function selecting the OTSi signal in receive direction from one of the two protection legs between the protection functions terminating the individual OTSi protection.  This individual OTSi protection scheme can be considered as a photonic 1+1 protection scheme (1+1 sub-network connection protection (SNCP) in ITU-T terminology). </del> <ins> requires dedicated photonic protection functions in the optical domain that are typically provided by dedicated protection hardware. These photonic protection functions are a photonic splitter function splitting the OTSi signal in transmit direction and a photonic selector function selecting the OTSi signal in receive direction from one of the two protection legs between the two protection functions terminating the individual OTSi protection.  This individual OTSi protection scheme can be considered as a photonic 1+1 protection scheme (1+1 sub-network connection protection (SNCP) in ITU-T terminology). In order to achieve short protection switching times, it is necessary that the OTSi signals of the two legs are identical in terms of wavelength, modulation format, FEC, etc., which means no receiver configuration changes when a protection switch at the selector occurs selecting the other leg.  This is important when 3R regenerators are needed between the two end-points terminating the protected segment, which typically is end-to-end. </ins> In case of individual OTSi protection, there are two network media channel paths associated with the OTSi signal.  In the YANG model,

Discussion:
draft-ietf-ccamp-optical-impairment-topology-URL for IETF 115 submission --> draft-ietf-ccamp-optical-impairment-topology-yang-URL Related to pull request URL Addressing and resolving .
Change:
ACME Order Object Fields (iana-order) <ins> ACME Authorization Object Fields (iana-authz) </ins> ACME Error Types (iana-error) ACME Resource Types (iana-resource)

Discussion:
Section 9.7 "New Registries" itemizes the subsections that include new IANA registries. We added a subsection for "Authorization Object Fields" but forgot to add a link to it from the top level 9.7 text. This commit adds that forward pointer.
Change:
8.1. The value of the Object-Security option SHALL contain the OSCORE flag <del> byte and the kid parameter as follows: </del> <ins> byte, the Partial IV parameter, the Context Hint parameter (length and value), and the kid parameter as follows: </ins> The first byte (= the OSCORE flag byte) encodes a set of flags and the length of the Partial IV parameter. <del> The three least significant bits, n, encode the Partial IV length.  If n = 0 then the Partial IV is not present in the </del> <ins> The three least significant bits encode the Partial IV length n.  If n = 0 then the Partial IV is not present in the </ins> compressed COSE object.  The values n = 6 and n = 7 is reserved.

Discussion:
This implements the change I suggested in , ie move everything but the ciphertext from CoAP payload to the option value. The text about kid being the last field is a draft, please modify if you have any better formulation.
Change:
4.2. This section covers required behavior of a TSN-aware MPLS (DetNet) <del> node using a TSN sub-network. </del> <ins> node using a TSN sub-network.  The implementation of TSN packet processing functions MUST be compliant with the relevant IEEE 802.1 standards. </ins> From the TSN sub-network perspective MPLS (DetNet) nodes are treated as Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware.

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
<del> HTTP </del> <ins> Applications that need a human-friendly, cross language, Unicode based data serialization language designed around the common native data types of dynamic programming languages. </ins> An empty fragment identifier references the root node.  A fragment identifier starting with "*" is to be interpreted as a YAML alias

Discussion:
Fix typical media type template problems Typos
In general, LGTM. About change controller, I was waiting for the feedback from the media type mailing list.
Change:
8.10. <del> IANA has added the well-known URI "edhoc" to the Well-Known URIs registry. </del> <ins> IANA has added the well-known URI "edhoc" to the "Well-Known URIs" registry under the group name "Well-Known URIs". </ins> URI suffix: edhoc

Discussion:
A new Resource Type (rt=) Link Target attribute like "URL" may be registered in the "Resource Type (rt=) Link Target Attribute Values" subregistry under the "Constrained RESTful Environments (CoRE) Parameters" registry.
That seems like a good idea.
Marco, do you want to provide a PR? Then we could merge that for -11
Done, see URL Note that the first commit is just about removing trailing whitespace to avoid compiling errors. The content you need is in the commit URL
Looks good. I tried to align the whole IANA section with RFC 8126. Then I merged.
Change:
Section 5.3; to match the "o=" line, a single dash SHOULD be used as the session name, e.g. "s=-".  Note that this differs from the advice in RFC4566 which proposes a single space, but as both "o=" <del> and "s=" are meaningless, having the same meaningless value seems clearer. </del> <ins> and "s=" are meaningless in JSEP, having the same meaningless value seems clearer. </ins> Session Information ("i="), URI ("u="), Email Address ("e="), Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=")

Discussion:
…eless.
Section 5.2.1 contains the statement "both 'o=' and 's=' are meaningless" -- this should be qualified with "in JSEP." These fields are not generally meaningless in all uses of SDP.
Sure.
Change:
the network (see mc-registration. A Resource Directory MAY provide hints about the content-formats it <del> supports in the links it exposes or registers, using the "ct" link </del> <ins> supports in the links it exposes or registers, using the "ct" target </ins> attribute, as shown in the example below.  Clients MAY use these hints to select alternate content-formats for interaction with the Resource Directory.

Discussion:
None of those meant any of (anchor,rel,rev), and all the other attributes that come from serializations should be called by what they are. Closes: URL
Working with RFC8288 in CoRAL I noticed that we're a bit sloppy on some concepts of web linking. This manifests in two related issues: We're talking of link attributes, where that's a term nowhere defined. (Used by RFC6690, but possibly they mean "attributes of CoRE links" and not "Core's use of link attributes", and even there only in the chapter name.) The information model we describe is more the model of the serialized data; the data model makes no distinction, for example, between and . The latter is something we can IMO let slide on account of practical readers having both in mind. The former poses the danger of aggravating the careless use of "link attributes" that'd describe the link-as-a-whole (something not covered by the data model, and thus incompatible with different serializations), but can easily be fixed in a search-and-replace PR coming right up.
Change:
If the server wishes to present the client with terms under which the ACME service is to be used, it MUST indicate the URI where such terms can be accessed in the "terms-of-service" subfield of the "meta" <del> field in the directory object, and the server SHOULD reject new- registration requests that do not contain "terms-of-service-agreed": true. </del> <ins> field in the directory object, and the server MUST reject new- registration requests that do not have the "terms-of-service-agreed" set to "true". </ins> If the client wishes to update this information in the future, it sends a POST request with updated information to the registration

Discussion:
Right now, it's not clear when the client needs to agree to the server's terms, and what the server should do if it needs the client to re-agree. This PR addresses both with a dedicated error code and some related behaviors.
Change:
adding a new version of herself using a new credential signed under a new IdentityKey, then performing a remove of the old leaf.  This is fine as long as the credential binds to the same identity for the <del> application.  If this verfication is not met, there is no </del> <ins> application.  If this verification is not met, there is no </ins> authentication guarantee at the application layer anyway.]] 6.3.

Discussion:
Yeah, I noticed that too as I was implementing. I will fix it in a “reconciliation with implementation” PR I’m working on.
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 0 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by - - Last week, 14 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 6 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 10 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 3 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 11 issues were created. Of these, 1 issues have been closed and 10 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 2 comments.

- - Last week, 11 pull requests were created, updated or merged. Last week, 6 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
<ins> The application will offer BUNDLE, but mark none of its streams as bundle-only.  This policy will allow all streams to be received by non-BUNDLE-aware endpoints, but require separate candidates to be gathered for each media stream. </ins> The application will BUNDLE all of its media streams, including data channels, on a single transport.  All streams other than the first will be marked as bundle-only.  This policy aims to minimize

Discussion:
LGTM
lgtm
If you know the remote side is going to use BUNDLE and RTCP mux, it's desirable to only gather a single set of ports, since the RTCP ports won't be used. Since max-bundle is already trying to minimize port gathering, it should probably assume rtcp mux. If there is a need to keep max-bundle as is, we could also add a fourth policy, e.g. force-bundle, that differs from max-bundle in that it forces use of RTCP mux.
I think we need another one, since currently max-bundle is minimally compatible with old endpoints and if you force rtcp-mux, then you will have ann interop problem. That's what I have on my slides now. Feel free to comment.
I can go with whatever the WG decides.
WG decision is to add an additional policy. Name will be force-bundle unless someone comes up with a better one.
Change:
for a device.  The last valid firmware should not have an expiration time. <ins> If a device has a flawed time source (either local or remote), an old update can be deployed as new. </ins> Mitigates: Implemented by:

Discussion:
Clarified several points: Remote secure clocks require authentication. This was assumed when using the "correctness guarantees" however that was not sufficiently clear. Risks associated with using a flawed clock for manifest expiry. Secure clock can be used for key expiry. Risk of flawed clock for key expiry is identical to not having key rotation.
Ben Kaduk wrote:
We might also discuss the risks when a device believes that it possesses a source of secure time but the timesource is actually flawed.
Change:
Some revisions of this draft specification use a different value (the Identifier field of a Setting in the HTTP/3 SETTINGS frame) for the <del> H3_DATAGRAM Settings Parameter.  This allows new draft revisions to </del> <ins> SETTINGS_H3_DATAGRAM setting.  This allows new draft revisions to </ins> make incompatible changes.  Multiple draft versions MAY be supported <del> by sending multiple values for H3_DATAGRAM.  Once SETTINGS have been sent and received, an implementation that supports multiple drafts MUST compute the intersection of the values it has sent and received, and then it MUST select and use the most recent draft version from the intersection set.  This ensures that both peers negotiate the same draft version. </del> <ins> by sending multiple values for SETTINGS_H3_DATAGRAM.  Once SETTINGS have been sent and received, an implementation that supports multiple drafts MUST compute the intersection of the values it has sent and received, and then it MUST select and use the most recent draft version from the intersection set.  This ensures that both peers negotiate the same draft version. </ins> 2.2.

Discussion:
This looks big but it consists of some minor operations H3DATAGRAM -> SETTINGSH3_DATAGRAM SETTINGS parameter -> setting Tweak the security considerations so it is explicit and grammar ain't borke
We deviate from the usual way of referring to settings, this will likely get picked up later on so may as well fix it now.
Change:
any significant limitations as all this data is meant for machine to machine communications and is not meant to be human readable. <del> Security considerations: Sensor data can contain a wide range of information ranging from information that is very public, such the outside temperature in a given city, to very private information that requires integrity and confidentiality protection, such as patient health information.  This format does not provide any security and instead relies on the transport protocol that carries it to provide security.  Given applications need to look at the overall context of how this media type will be used to decide if the security is adequate. </del> <ins> Security considerations: See sec-sec of RFC-AAAA. </ins> Interoperability considerations: Applications should ignore any JSON key value pairs that they do not understand.  This allows backwards

Discussion:
Alternatively we can have the same text 9 times instead of 8
Alexey confirmed in the CoRE session that this is OK, so let's go forward with this.
The IANA types review list explicitly wanted all of this repeated because they don't read the draft on the email and each type needs it's own email. It is insane. So I would not make this change. LGTM
Change:
binary CBOR value is base64-encoded (RFC4648).  The data value after base64 decoding is shown with CBOR diagnostic notation in ex-2-cbor. <ins> 1.1. As with SenML in general, there is no expectation that the creator of a SenML pack knows (or has negotiated with) each consumer of that pack, which may be very remote in space and particularly in time. This means that the SenML creator in general has no way to know whether the consumer knows: each specific media-type-name used each parameter and each parameter value used each content coding in use each Content-Format number in use for a combination of these What SenML, as well as the new fields defined here, guarantees is that a recipient implementation when it needs to be updated to understand these field values and the values controlled by them; registries are used to evolve these name spaces in a controlled way.  SenML packs can be processed by a consumer while not understanding all the information in them, and information can generally be preserved in this processing such that it is useful for further consumers. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Discussion:
7de7a76 Update the ABNF to refer to httpbis-semantics; include quoted-pair 7775765 Switch from 7230/7231 to httpbis-semantics 0a57952 Address the question Roman Danyliw did not ask :-)
Change:
records can be made to the Unencrypted Resolver (or some other resolver the DNS client has been configured to use). <ins> If the recursive resolver that receives this query has no Designated Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa" SUDN. </ins> 4.1. In order to be considered an authenticated Designated Resolver, the

Discussion:
This addresses the remaining portions of not address by a prior PR
Migrated from original DEER issue: URL
The Special Use Domain Name (SUDN) URL needs more clarification. Specifically: Queries against the .arpa nameservers The draft should mention that .arpa is a delegated zone, currently served by the root nameservers. Clients that query a resolver that is unaware of this requirement will "leak" queries to the root nameservers. When URL is not present in a resolver configuration Section 6.1 discusses how a forwarder should behave and suggests that results should not be cached other than for Equivalent Encrypted Resolvers under their control. How is that determined? There is no discussion around a non-forwarding resolver's behaviour. Should it return NODATA? Forwarding queries to URL will attempt to attach a client to an upstream resource's equivalent resolver. If that equivalent resolver's cert doesn't include the forwarder, the client must reject the answer. Is it not therefore the case that the forwarder caching behaviour is irrelevant? All valid responses to this query must be equivalent to the forwarder itself. When URL is present in a resolver configuration I would suggest some clarification wording something like this: The expectation is that this record set will detail equivalent resolvers. A client that chooses not to interact with any of these equivalent resolvers SHOULD continue to use the unencrypted resolver, honouring the SVCB TTL. When the SVCB TTL expires, the client may choose to re-query in an attempt to discover newly available equivalents. I would suggest (prefer?) changing the SUDN behaviour so that queries against it are never sent upstream. Resolvers (and forwarders) that do not have a configured URL RRset should return NODATA. This would mean that URL SUDN RRsets are always specific to the IP queried.
It may be good to model the advice after RFC8880, which defines URL
I am leaving this open so I can re-review the text after addressing other PRs; PR 14 addressed some of the points raised in this issue but not all of them.
Change:
18.1. <ins> Transport parameters with an identifier of the form "31 * N + 27" for integer values of N are reserved to exercise the requirement that unknown transport parameters be ignored.  These transport parameters have no semantics, and may carry arbitrary values. 18.2. </ins> This section details the transport parameters defined in this document.

Discussion:
NAME I added IANA considerations, analogous to those in the HTTP doc for the stream type.
We have space for private transport parameters and a process for assigning new standard transport parameters. However, since we do not apply GREASE to transport parameters, we leave ourselves open to that flexibility ossifying. I'm happy to produce a PR to address this in the spec.
During interop in London we found an implementation that failed the handshake upon seeing an unknown transport parameter. I think applying GREASE to transport parameters is a great idea.
Discussed in London, NAME to prepare a PR
NAME any progress here?
I have prepared something. I can open a pr
NAME sorry I totally dropped the ball here! I had text ages ago and was circling back today finally. Thanks NAME for seeing to it.
Thanks Marten!Thanks for writing this up!Need to fix the examples, but otherwise looks good.