jiebi/CodeConvo huggingface dataset:
Code change:
over loss, and may be more accepting of having slightly more latency to increase guarantee of delivery. <del> 3.3.1. </del> <ins> 3.2.1. </ins> Where media is received from a source for onwards handling into a distribution platform.  The media may comprise of multiple audio and/

Related discussion:
text: NAME I think this is ready for review and merging .
Duplicated "without without waiting" in Section 2.1. I wish I had spotted "where a user wishes to observe or control the graphical user interface of another computer through local user interfaces" in 3.1.2 - I'd suggest saying this as "where a user wishes to observe or control the graphical user interface of another computer through user interfaces that are local to the user". I think "This may include audio from both microphone(s) and/or cameras, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation" in 3.1.3 might need adjusting. Doesn't this need to say, "This may include audio from microphone(s) and/or cameras, and may include "screen sharing" or inclusion of other content such as slide, document, or video presentation"? (Also, we named everything except video as a media type, but if we're changing that paragraph anyway, we can add video as well) in 3.2, I had difficulty parsing "As this has a much larger total number of participants - as many as Live Media Streaming , but with the bi-directionality of conferencing, this should be considered a "hybrid"." I wasn't sure "much larger than what?" Is this intended to say something like "This use case can have an audience as large as Live Media Streaming as described in Section 3.3.3, but also relies on the interactivity and bi-directionality of conferencing as in Video Conferencing as described in Section 3.1.3. For this reason, this type of use case can be considered a "hybrid". (if we're forward-referencing section 3.3.3 in Section 3.2, this might be clearer if we swapped the order of Sections 3.2 and 3.3) In section 3.3.1, are there any non-hypothetical media types beyond "audio and/or video"? In Section 3.3.3, I asked you to distinguish between the live edge and the trailing edge (thank you for that), but I didn't realize that "either because the local player falls behind edge" was now unqualified. Is this "either because the local player falls behind the live edge**"?
Code change:
over loss, and may be more accepting of having slightly more latency to increase guarantee of delivery. <del> 3.3.1. </del> <ins> 3.2.1. </ins> Where media is received from a source for onwards handling into a distribution platform.  The media may comprise of multiple audio and/

Related discussion:
text: In 4.9.1, "this is infeasible in many use cases where provisioning of client TLS certificates is unsupported or infeasible." has two "infeasible"s. Perhaps one could be "impractical"? Your choice which, of course.
In submitting the -00 working group version, we tripped over an incompatibility between XML2RFC and google-i18n-address 3.0.0. The details are at URL and at URL I took the shortcut of removing the country: attributes for the authors in -00, but (per the comments on those issues, a version of XML2RFC that has been deployed, so we can add our country attributes back when we're fixing the nits identified in this issue. And NAME says it's "The Netherlands", but I'll let NAME and NAME wrestile that one out ... :zippermouthface:
Code change:
Track Box in the initialization fragment.  A Common Media Application Format Segment CMAF meets all these requirements. <del> Each OBJECT message (object) MUST start with an initialization segment, or MUST depend on a OBJECT that does.  The rest of the OBJECT message MAY be a media segment. </del> Media fragments can be packaged at any frequency, causing a trade-off between overhead and latency.  It is RECOMMENDED that a media fragment consists of a single frame to minimize latency.

Related discussion:
text: It's difficult to populate and has fringe benefit at best. Let's revisit this in the future if it's actually useful. removed after discussion in
To explain a bit more in-depth: The goal of the dependency list was to give relays the information required to know which frames are droppable. This doesn't actually accomplish that goal since a frame could be a reference for a future frame. It's a lot of state to keep track of and it's unlikely to be used by even the smartest relay. It's much simpler and probably a better user experience for a relay to obey the delivery order. The decoder doesn't actually need this list since the references are stored in the codec itself. A mismatch between the Warp dependency list and the codec reference list sounds pretty awful. Accurately populating the Warp dependency list requires parsing the codec bitstream, which is more difficult and expensive than it needs to be. The only immediate use-case for the dependency list is to mark init segments. We could have a separate field for that, or put the init segment in the CATALOG itself. There's a possible use-case for SVC but again, a relay can just follow delivery order and the decoder should be able to piece together dependencies from the underlying codec.
I went ahead and merged because I haven't heard a positive reaction to the dependency list. We can always make a PR to add it back and actually discuss the merits.
Code change:
SD-JWT-based Verifiable Credentials SD-JWT.VC introduce the usage of Status List in Section 3.2.2.2.  The "status" object uses the same <del> encoding as a JWT as defined in referenced-token-jwt. </del> <ins> encoding as a JWT as defined in referenced-token-jose. </ins> The following is a non-normative example for a Referenced Token in SD-JWT-VC serialized form as received from an Issuer:

Related discussion:
text: Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho
Code change:
10.2.2. <del> IANA is asked to establish a registry of hash algorithm identifiers, named "Hash Algorithms", with the following registration procedures: TBD The "Hash Algorithms" registry initially consists of: The designated expert(s) should ensure that the proposed algorithm has a public specification and is suitable for use as a cryptographic hash algorithm with no known preimage or collision attacks.  These attacks can damage the integrity of the ledger. 10.2.3. </del> IANA is asked to establish a registry of signature algorithm identifiers, named "Signature Algorithms", with the following registration procedures: TBD

Related discussion:
text: Changes: Remove initial version from CCF tree alg identifier. The idea is to not be linked directly to major CCF software releases but rather version independently here. For now, there is no need to include a version number in the tree alg identifier. Remove CCF hash alg parameter as that is always implied by the signature alg. CCF signs pre-hashed data (the Merkle tree root) and doesn't hash twice.
Code change:
header field in the request (field.range). <del> A client SHOULD NOT generate content in a GET request.  Content received in a GET request has no defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (request.smuggling). </del> <ins> Although request message framing is independent of the method used, content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (request.smuggling).  A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.  An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain. </ins> The response to a GET request is cacheable; a cache MAY use it to satisfy subsequent GET and HEAD requests unless otherwise indicated

Related discussion:
text: Actually it is even already used and documented: the broadly used ElasticSearch explicitly documents how to perform JSON search requests using : URL So please let's stick to "SHOULD NOT" with Julian's "unless negotiated via other means" or something like this, instead of suddenly adding dangerous exceptions to the protocol and breaking interoperability between already deployed and working components.
Code change:
This document establishes a registry for HTTP/2 settings.  The "HTTP/2 Settings" registry manages a 16-bit space.  The "HTTP/2 <del> Settings" registry operates under the RFC5226 for values in the range from 0x0000 to 0xefff, with values between and 0xf000 and 0xffff being reserved for Experimental Use. </del> <ins> Settings" registry operates under the RFC8126. </ins> New registrations are advised to provide the following information:

Related discussion:
text: This is part of the fix for . This part removes the experimental range for frame types and settings. Also updates to use section references to RFC 8126, which replaces RFC 5226.
Nice clean change. No notes.
Code change:
Stream identifiers cannot be reused.  Long-lived connections can result in an endpoint exhausting the available range of stream identifiers.  A client that is unable to establish a new stream <del> identifier can establish a new connection for new streams. </del> <ins> identifier can establish a new connection for new streams.  A server that is unable to establish a new stream identifier may send a frame to require the client to establish a new connection. </ins> 5.1.2.

Related discussion:
text: Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.
Code change:
appear, but each of them has a different salt. <del> 10.5. </del> <ins> 10.4. </ins> To ensure privacy of claims that are selectively disclosable, but are not being disclosed in a given presentation, the hash function MUST

Related discussion:
text: Attempt to better explain how salt in the Disclosure makes guessing the preimage of the digest infeasible Consolidate salt entropy and length security consideration subsections
question from an email, my response: The exchange makes me think a brief mention/explanation what salt does/provides in the SD-JWT context would be a worthwhile addition. Maybe just add or modify a sentence or two in sec 10.3. And/or something in URL where the salt value in the Disclosure is introduced/described.
Hi Brian, just check for understanding: does the issuer send the clear text values of the disclosed claims to the holder and verifier or does the issuer only send the salted hashes? +------------+ +------------+ | Issues SD-JWT including all Disclosures | v +------------+ +------------+ | Presents SD-JWT including selected Disclosures | v +-------------+ + + +-------------+ +-------------+| +-------------+
I'm sorry but I don't quite understand the question or how it relates to the small change I'm suggesting in this issue.
FYI, I was asked what the salt does by an IETF attendee yesterday. I support explaining this in the draft.
PR has some proposed text
Code change:
traffic sharing a bottleneck), with similar impacts on congestion control. <del> 5.8. </del> <ins> 5.9. </ins> Multipath transport protocols permit more than one path to be differentiated and used by a single connection at the sender.  A

Related discussion:
text: Added first-cut of minimum delay text. Intended to
Delay based congestion control protocols are making an assumption that the observed RTT is the sum of a constant "min delay" and a variable queuing delay. This assumption may not be valid on wireless links, as delays vary when the distance between mobile endpoint and base station increases, or when changing transmission condition cause the radios to adopt different modulation and coding strategies. I suspect we also have these "variable delays" in satellite services, especially when using constellations of low orbit satellites. The state of the art is not very good. BBR for example recognizes its dependency on accurate estimate of the min RTT, but has to resort to some kind of periodic reset if measurements of RTT kept over RTT min for 10 seconds -- which is both quite long for some apps, and quite annoying for real time apps suffering a transmission issue every ten seconds. LEDBAT++ does something similar. I think these "variable delays" link are good candidates for "special case" links, to be mentioned in a separate section.
The variable delay part applies to most satellite broadband access using GEO also - not because of propagation usually, but more a result of radio resource sharing. It might well apply to some other technologies that use a shared capacity pool.
Min delay variation strikes me as a bit of a corner case -- perhaps it can be an optional case to evaluate. The other piece is delay variation is not always congestion -- this is IIUC very common in wireless and is part of that mandatory case.
In think this is something like: An Internet Path can include simple links, where the minimum delay is the propagation delay, and any additional delay can be attributed to link buffering. In this case, a congestion controller could reduce the sending rate to the point of minimum buffering while still preserving the maximum throughput. An internet Path can also include complex subnetworks where the minimum delay changes over various time scales. This occurs when a subnet changes the forwarding path to optimise capacity, resilience, etc. It could also arise when a subnet uses a capacity management method where the available resource is periodically distributed among the active nodes and where a node might then have to buffer data until an assigned transmission opportunity. Variation also results when a higher priority diffserv traffic classic prompts the transmission by a lower class.
Code change:
traffic sharing a bottleneck), with similar impacts on congestion control. <del> 5.8. </del> <ins> 5.9. </ins> Multipath transport protocols permit more than one path to be differentiated and used by a single connection at the sender.  A

Related discussion:
text: In these cases, the delay varies as a function of external factors and attempting to infer congestion from an increase in the delay results in reduced throughput.
The delay will also change when the wireless path between two wireless nodes becomes longer, or slower, or shorter, or faster. Or when a wireless router changes the schedule of transmission and starts polling a wireless station more often. or less often. To give an extreme example, suppose a spacecraft flying away from earth at 12,000 km/h. Every hour, the delay will increase by 40 ms.
Sure, however that requirement is very specific to certain systems - my point is that even for fixed cabled and broadband wireless systems, the base delay changes.
I suggest the language "non stationary minimum delay" to encompass all causes that resemble some form of route or path change, explicitly including LEO and mobile motion. It doesn't really cover link layer re transmissions or delays caused by link scheduling algorithms, but these are short term variations that are more likely to be statistically similar to IP queuing delay. I would use the term "hidden queues" to refer to unmanaged queues that (almost) never incur significant backlog but do occasionally cause jitter and generally can not be observed at the IP queuing layer.
NAME will add something in Sec 5 ("Special Cases")
Code change:
is preferred; digest-algorithm token values MUST be compared in a case-insensitive fashion. <ins> Every digest-algorithm defines its computation procedure and encoding output.  Unless specified otherwise, comparison of encoded output is case-sensitive. </ins> The "HTTP Digest Algorithm Values Registry", maintained by IANA at https://www.iana.org/assignments/http-dig-alg/ [3] registers digest- algorithm values.  Registrations MUST include the following fields:

Related discussion:
text: add registration policy cc: NAME and NAME to URL Using RFC policy avoids the issues we had to face to refresh the current table. See
NAME now it's Specification Required :)
This specification obsoletes 3230 and updates the IANA registry to point to it, but doesn't specify what the registration policy actually is.
Related to NAME says
See
NAME do we need ? [x] 5. 'The IANA acts a registry' reads oddly; it maintains the registry. Also, saying 'the registry contains the tokens listed below' is misleading; these are initial registrations, which can be modified and added to after the RFC is published. Also, these might be better placed in IANA Considerations.[x] 5. There should not be RFC2219-MUSTs in IANA registry text. This can be addressed by having a requirement similar to "Deprecated digest algorithms MUST NOT be used."[ ] 5. The ability to have a digest algorithm that ignores content-codings is something of a surprise after reading section 2; it needs to be at least mentioned up there.
I'm sure I made this comment somewhere but I've lost it. I don't think we should mandate RFC required, that a very high bar for algorithms (and their users) that most likely developed the algoithm elsewhere already. Instead seem like a better option here
NAME imho registering new algos should be done via an RFC, this doesn't imply that those algorithms should be defined in an RFC. While it is fair to delegate the registration to an external specification, I think the approach of an RFC (eg URL ) is a lot more clean and improves the overall interoperability. It is important to note that any type of RFC is sufficient (currently Standards Track, BCP, Informational, Experimental, or Historic). In any case, I don't think this should be a game-stopper, so if there's general consensus on "Specification Required", that's ok.
I don't think running an RFC process can provide any meaningful value to the registration requirements. I mean, that's going to add like a year of overhead to something as simple as "use algorithm $foo with token , the output is encoded using base64".
The key to Specification Required is the Designated Experts. If they do they job you basically get what you need.
Code change:
is preferred; digest-algorithm token values MUST be compared in a case-insensitive fashion. <ins> Every digest-algorithm defines its computation procedure and encoding output.  Unless specified otherwise, comparison of encoded output is case-sensitive. </ins> The "HTTP Digest Algorithm Values Registry", maintained by IANA at https://www.iana.org/assignments/http-dig-alg/ [3] registers digest- algorithm values.  Registrations MUST include the following fields:

Related discussion:
text: If there's any question from the DEs they can always kick it back out for further review.
NAME Seems that NAME is on the same page URL ;) So let it be Specification Required! Move on :)
Code change:
4.1. <ins> The use cases described in this section have one particular attribute in common - the target latency for these cases are on the order of one or two RTTs.  In order to meet those targets, it is not possible to rely on protocol mechanisms that require multiple RTTs to function effectively.  For example, When the target latency is on the order of one RTT, it makes sense to use FEC RFC6363 and codec-level packet loss concealment RFC6716, rather than selectively retransmitting only lost packets. These mechanisms use more bytes, but do not require multiple RTTs in order to recover from packet loss. When the target latency is on the order of one RTT, it is impossible to use congestion control schemes like BBR I-D.draft- cardwell-iccrg-bbr-congestion-control, since BBR has probing mechanisms that rely on temporarily inducing delay and amortizing the consequences of that over multiple RTTs. This may help to explain why these use cases often rely on protocols such as RTP RFC3550, which provide low-level control of packetization and transmission. </ins> 4.1.1. *Senders/Receivers*: One to One *Bi-directional*: Yes *Latency*:

Related discussion:
text: WebRTC avoids these unnecessary dependencies which is how it's able to rapidly respond to congestion to keep latency low. I've been working on a "latency theory" document if any of these ideas are resonating with people. I feel like it's too early though, and we should be focusing on the use-cases and requirements instead.
NAME - please let me know when you think it's not too early to focus on "latency theory". I'd love to know more (in particular, I'd love to know if I'd be able to contribute effectively to that important topic). Just filing this away for now, as you suggest.