jiebi/CodeConvo huggingface dataset:
Code change:
Some applications might want to send messages, and not care about the order of delivery, but still get reliability. QUIC streams give them reliability, but within a stream it enforces order of delivery. This datagram proposal gives unordered delivery of messages, but without reliability. Why not provide datagrams with optional (opt-in) reliability? It shouldn't be a lot of extra work for QUIC implementors to provide reliable datagrams as well as unreliable, given that retransmission is already there for QUIC streams. (I guess an application could create a separate QUIC stream for each unordered reliable message. That might work, but seems ugly and may have some overhead.)
What you describe can already be accomplished using streams: each “reliable datagram” is its own stream. That provides reliable delivery without ordering between independent datagrams. I don’t think we need to add optional reliability to the datagram spec.
Streams are very lightweight, and well suited to this task. Beware applying intuition from TCP too heavily.
So, here's a suggestion then: since I'm sure I'm not the only person who is going to think of this, maybe add some verbiage to the spec explaining why supporting reliable datagrams is unnecessary?
Sounds good. We can keep this issue open as requesting an editorial change.

Related discussion:
text: This document defines two new DATAGRAM QUIC frame types, which carry application data without requiring retransmissions. <ins> Note that DATAGRAM frames are only meant for unreliable transmissions.  Reliable transmission is already supported by QUIC via STREAM frames. </ins> Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org [3] or on the GitHub repository which contains the draft: https://github.com/quicwg/datagram [4].
Code change:
The IANA section was added before the QUIC registries had a notion of permanent vs provisional, and we then forgot to update it. This PR fixes that oversight.
Latest change looks good to me
Noticed during Shepherd review. All of the core types registered in RFC 9000 simply link to the relevant document (RFC 9000) and section in the document where the protocol element is defined. In contrast, in datagram's IANA considerations section, the transport parameter and frame type registrations include the required field with some text that is already included in the document. This will manifest as a weird juxtaposition in the IANA table. I suggest you simply reference the section 3 and section 4 respectively. If you really want some prose (I don't recommend that) then it can be added as a note to the table.
I noticed that when writing and I agree, we should just list "This specification" in there as most RFCs do.
Noticed during the shepherd writeup of IANA considerations: The document is attempting to register: maxdatagramframe_size Transport Parameter with value 0x0020 DATAGRAM frame type with values 0x30 and 0x31 According to IANA (URL) registrations can be of different types. Here the requested values are in the bracket. So I suggest that the document state clearly that this is a request for permanent registration of these types.
Agreed. Wrote up to fix this.
LGTM, thanks!

Related discussion:
text: 7. <ins> 7.1. </ins> This document registers a new value in the QUIC Transport Parameter <del> Registry: </del> <ins> Registry maintained at <https://www.iana.org/assignments/quic/ quic.xhtml#quic-transport>. </ins> <del> 0x0020 (if this document is approved) </del> <ins> 0x20 (if this document is approved) </ins> max_datagram_frame_size <del> A non-zero value indicates that the endpoint supports receiving unreliable DATAGRAM frames.  An endpoint that advertises this transport parameter can receive DATAGRAM frames from the other endpoint, up to and including the length in bytes provided in the transport parameter.  The default value is 0. </del> <ins> permanent This document </ins> <del> This document also registers a new value in the QUIC Frame Type registry: </del> <ins> 7.2. This document registers two new values in the QUIC Frame Type registry maintained at <https://www.iana.org/assignments/quic/ quic.xhtml#quic-frame-types>. </ins> 0x30 and 0x31 (if this document is approved) DATAGRAM <del> Unreliable application data </del> <ins> permanent This document </ins> 8.
Code change:
See .
iirc there was a discussion on stuff. In general I'm ok with just NAME do you see any issue with that?
No issue, I was aware of the BCP and I think this case fits the first provision for segregating the name spaces in the Appendix B, so any one of the proposed solutions there, including yours, is fine with me.

Related discussion:
text: extension parameters: To avoid clashes, implementers SHOULD prefix unregistered parameters <del> with an "x-<vendor>" identifier, e.g. "x-acme-policy", "x-acme- burst".  While it is useful to define a clear syntax and semantics even for custom parameters, it is important to note that user agents are not required to process quota policy information. </del> <ins> with a vendor identifier, e.g. "acme-policy", "acme-burst".  While it is useful to define a clear syntax and semantics even for custom parameters, it is important to note that user agents are not required to process quota policy information. </ins> 2.2.
Code change:
Closes: URL
In the lookup filtering description, we talk about how href can be queried for (that it only applies in the URI form), but say nothing about anchor (to which the same applies in principle, with slightly different statements about application to the endpoints). Thanks Christer for pointing that out. As RFC6690 contains a lookup example for ?anchor=, we may want to add one here as well.

Related discussion:
text: references) and are matched against a resolved link target.  Queries for endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in URI form otherwise; the RD SHOULD recognize <del> either. </del> <ins> either.  The "anchor" attribute is usable for resource lookups, and, if queried, MUST be for in URI form as well. </ins> Endpoints that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource
Code change:
Something around "whether many registrations are expected over time" is supposed to be said according to BCP26, but it seems this belongs in the shepherd write-up, where it is now being added. To be merged right away.

Related discussion:
text: registration if it were not to be used in lookup or attributes, but would make a bad parameter for lookup, because a resource lookup with an "if" query parameter could ambiguously filter by the registered <del> endpoint property or the RFC6690 target attribute).  It is expected that the registry will receive between 5 and 50 registrations in total over the next years. </del> <ins> endpoint property or the RFC6690 target attribute). </ins> 9.3.1.
Code change:
... as promised for yesterday (oops)
ad "what is sub": it's DNS-SD's syntax for subtypes (RFC6763 Section 7.1). Might also be URL ("Subtype strings are not required to begin with an underscore, though they often do").
Looks good to me.
There are several ways specified for finding a host serving an RD: static (unicast or anycast, addresses or DNS? could contain full RD path (as in LWM2M)?) various neighbor discovery derived RDAO the border router (ABRO) "other ND options that happen to point to servers (such as RDNSS)" might-be-defined DHCPv6 options multicast (all-coap-nodes + .well-known/core; serves the path by design) There is an open issue to describe how this can be used with DNS-SD (), and it came up 2017-04-07 that discovery via mDNS by those mechanisms might be possible but is not advisable. Can we give a set of discovery options that should be supported by all general-purpose clients and servers to avoid fragmentation where one vendor's clients expect an RDAO while the other vendor's server relies on clients doing a multicast? Can we say anything about which options are recommended to use, and which are rather to be viewed as shortcuts in extremely constrained cases? Using RDNSS would be a candidate for such a statement. Maybe those cases are better described as "explicitly configured to use whichever RDNSS is announced", so this is something that's better than static configuration but still not to be expected from a generic client.
The new section 4 introduced in URL takes care of this.

Related discussion:
text: Changed the lookup interface to accept endpoint and Domain as query string parameters to control the scope of a lookup. <ins> Editorial Comments [_1] cabo: What is _sub here? </ins>
Code change:
From Stephane:
Shouldn't the CA / cert hierarchy be a point of control? For example, KZ is requiring users to install their CA, to allow them to MITM all traffic: URL Another example of CA abuse is ROA whacking, RPKI manipulation, etc.: URL
Also got this feedback from Will Scott:

Related discussion:
text: Internet Backbone: If a censor controls the gateways into a region, they can filter undesirable traffic that is traveling into and out of the region by sniffing and mirroring at the relevant <del> exchange points.  Censorship at this point-of-control is most </del> <ins> exchange points.  Censorship at this point of control is most </ins> effective at controlling the flow of information between a region and the rest of the Internet, but is ineffective at identifying content traveling between the users within a region. Internet Service Providers: Internet Service Providers are perhaps <del> the most natural point-of-control.  They have a benefit of being </del> <ins> the most natural point of control.  They have a benefit of being </ins> easily enumerable by a censor paired with the ability to identify the regional and international traffic of all their users.  The censor's filtration mechanisms can be placed on an ISP via
Code change:
From Stephane:
Shouldn't the CA / cert hierarchy be a point of control? For example, KZ is requiring users to install their CA, to allow them to MITM all traffic: URL Another example of CA abuse is ROA whacking, RPKI manipulation, etc.: URL
Also got this feedback from Will Scott:

Related discussion:
text: than potentially excluding content, users, or uses of their service. <ins> Certificate Authorities: Authorities that issue cryptographically secured resources can be a significant point of control. Certificate Authorities that issue certificates to domain holders for TLS/HTTPS or Regional/Local Internet Registries that issue Route Origination Authorizations to BGP operators can be forced to issue rogue certificates that may allow compromises in confidentiatlity guarantees - allowing censorship software to engage in identification and interference where not possible before - or integrity degrees - allowing, for example, adversarial routing of traffic. </ins> At all levels of the network hierarchy, the filtration mechanisms used to detect undesirable traffic are essentially the same: a censor sniffs transmitting packets and identifies undesirable content, and
Code change:
From Stephane:
Shouldn't the CA / cert hierarchy be a point of control? For example, KZ is requiring users to install their CA, to allow them to MITM all traffic: URL Another example of CA abuse is ROA whacking, RPKI manipulation, etc.: URL
Also got this feedback from Will Scott:

Related discussion:
text: domain all other DNS servers will be unable to properly forward and cache the site.  Domain name registration is only really a risk where undesirable content is hosted on TLD controlled by the censoring <del> country, such as .cn or .ru Anderson-2011. </del> <ins> country, such as .cn or .ru Anderson-2011 or where legal processes in countries like the United States result in domain name seizures and/ or DNS redirection by the government Kopel-2013. </ins> 6.3.
Code change:
Tweaks to add the D values, explanations about D, etc.
We might want to check that the subsequent registries all have an appropriate value in the column.

Related discussion:
text: Changed the registry policy to: <del> Updated the "Reference" to also refer to this document. </del> <ins> Updated the "Reference" to refer to this document instead of RFC8447. </ins> See expert-pool for additional information about the designated expert pool.
Code change:
Tweaks to add the D values, explanations about D, etc.
We might want to check that the subsequent registries all have an appropriate value in the column.

Related discussion:
text: Add a "Recommended" column with the contents as listed below. This table has been generated by marking Standards Track RFCs as <del> "Y" and all others as "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126. IESG Approval is REQUIRED for a Y->N transition. </del> <ins> "Y", "truncated_hmac" (4) and "connection_id (deprecated)" (53) as "D", and all others as "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N, Y->D, and D->Y|N transitions. </ins> IANA [SHALL update/has added] the following notes: The extensions added by I-D.ietf-tls-rfc8446bis are omitted from the <del> above table; additionally, token_binding is omitted, since RFC8472 specifies the value of the "Recommended" column as for this extension. </del> <ins> above table.  Likewise, extensions defined after RFC8447 are also not listed in the table as those RFCs specify the value of the extension's "Recommended"; extensions points defined after RFC8447 include token_binding, compress_certificate, record_size_limit, pwd_protect, pwd_clear, password_salt, ticket_pinning, tls_cert_with_extern_psk, delegated_credentials, supported_ekt_ciphers, connection_id, external_id_hash, external_session_id, quic_transport_parameters, ticket_request, and dnssec_chain. </ins> I-D.ietf-tls-rfc8446bis also uses the TLS ExtensionType Values registry originally created in RFC4366.  The following text is from
Code change:
Tweaks to future proof document.
Spencer had the following comment: I found the reference to MMUSIC WG in When a new codec is specified, and the SDP for the new codec is specified in the MMUSIC WG, no other standardization should be required for it to be possible to use that in the web browsers. to be odd. MMUSIC may be around forever, but this work might be refactored at some point in the future. Is the point that When SDP for a new codec is specified, no other standardization should be required for it to be used in the web browsers. Or is there another way to say this? I'm also wondering if the statement is true for any WebRTC endpoint, not just browsers.

Related discussion:
text: gateway to convert between the signaling on the web side to the SIP signaling may be needed. <del> When a new codec is specified, and the SDP for the new codec is specified in the MMUSIC WG, no other standardization should be required for it to be possible to use that in the web browsers. Adding new codecs which might have new SDP parameters should not change the APIs between the browser and Javascript application. As soon as the browsers support the new codecs, old applications written before the codecs were specified should automatically be able to use the new codecs where appropriate with no changes to the JS applications. </del> <ins> When an SDP for a new codec is specified, no other standardization should be required for it to be possible to use that in the web browsers.  Adding new codecs which might have new SDP parameters should not change the APIs between the browser and Javascript application.  As soon as the browsers support the new codecs, old applications written before the codecs were specified should automatically be able to use the new codecs where appropriate with no changes to the JS applications. </ins> The particular choices made for WebRTC, and their implications for the API offered by a browser implementing WebRTC, are described in I-
Code change:
From Ben Campbell's review:
Second point is fixed by . I'm not sure the third point is an improvement.
SSL is used exactly once, as part of the acronym "TURN/SSL". This is also the first mention of TURN, but the second was much more convenient to attach the expansion to. Given that it was so awkward to attach them, I included a new section listing the "used protocols" instead.

Related discussion:
text: elements described. TCP RFC0793.  This is used for HTTP/WebSockets, as well as for <del> TURN/SSL and ICE-TCP. </del> <ins> TURN/TLS and ICE-TCP. </ins> For both protocols, IPv4 and IPv6 support is assumed.
Code change:
From Ben Campbell's review:
Second point is fixed by . I'm not sure the third point is an improvement.
SSL is used exactly once, as part of the acronym "TURN/SSL". This is also the first mention of TURN, but the second was much more convenient to attach the expansion to. Given that it was so awkward to attach them, I included a new section listing the "used protocols" instead.

Related discussion:
text: This specification does not assume that the implementation will have access to ICMP or raw IP. <ins> The following protocols may be used, but can be implemented by a WebRTC endpoint, and are therefore not defined as "system-provided interfaces": TURN - Traversal Using Relays Around NAT, STUN - Session Traversal Utilities for NAT, ICE - Interactive Connectivity Establishment, RFC5245 TLS - Trasnsport Layer Security, DTLS - Datagram Transport Layer Security, RFC6347. </ins> 3.2. Web applications running in a WebRTC browser MUST be able to utilize
Code change:
As described in URL
In the Dallas presentation on “transports” you stated that the reference to proxy authentication would be restored (See URL) but it does not seem to have happened. This is an oversight. (Noted by Andy Hutton)

Related discussion:
text: The WebRTC implementation MAY support accessing the Internet through an HTTP proxy.  If it does so, it MUST support the "connect" header <del> as specified in I-D.ietf-httpbis-tunnel-protocol. </del> <ins> as specified in I-D.ietf-httpbis-tunnel-protocol, and proxy authentication as described in Section 4.3.6 of RFC7231 and RFC7235 MUST also be supported. </ins> 3.5.
Code change:
I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

Related discussion:
text: 4. <del> This section describes a typical RTCWeb session and shows how the </del> <ins> This section describes a typical WebRTC session and shows how the </ins> various security elements interact and what guarantees are provided to the user.  The example in this section is a "best case" scenario in which we provide the maximal amount of user authentication and
Code change:
I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

Related discussion:
text: the calling service via HTTPS and so know the origin with some level of confidence.  They also have accounts with some identity provider. This sort of identity service is becoming increasingly common in the <del> Web environment in technologies such (BrowserID, Federated Google Login, Facebook Connect, OAuth, OpenID, WebFinger), and is often provided as a side effect service of a user's ordinary accounts with some service.  In this example, we show Alice and Bob using a </del> <ins> Web environment (with technologies such as BrowserID, Federated Google Login, Facebook Connect, OAuth, OpenID, WebFinger), and is often provided as a side effect service of a user's ordinary accounts with some service.  In this example, we show Alice and Bob using a </ins> separate identity service, though the identity service may be the same entity as the calling service or there may be no identity service at all.
Code change:
I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

Related discussion:
text: freshness", i.e., allowing Alice to verify that Bob is still prepared to receive her communications so that Alice does not continue to send large traffic volumes to entities which went abruptly offline.  ICE <del> specifies periodic STUN keepalizes but only if media is not flowing. Because the consent issue is more difficult here, we require RTCWeb </del> <ins> specifies periodic STUN keepalives but only if media is not flowing. Because the consent issue is more difficult here, we require WebRTC </ins> implementations to periodically send keepalives.  As described in Section 5.3, these keepalives MUST be based on the consent freshness mechanism specified in I-D.muthu-behave-consent-freshness.  If a
Code change:
I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

Related discussion:
text: NOT be permitted to control the local ufrag and password, though it of course knows it. <del> While continuing consent is required, that ICE RFC5245; Section 10 keepalives STUN Binding Indications are one-way and therefore not sufficient.  The current WG consensus is to use ICE Binding Requests for continuing consent freshness.  ICE already requires that implementations respond to such requests, so this approach is maximally compatible.  A separate document will profile the ICE timers to be used; see I-D.muthu-behave-consent-freshness. </del> <ins> While continuing consent is required, the ICE RFC5245; Section 10 keepalives use STUN Binding Indications which are one-way and therefore not sufficient.  The current WG consensus is to use ICE Binding Requests for continuing consent freshness.  ICE already requires that implementations respond to such requests, so this approach is maximally compatible.  A separate document will profile the ICE timers to be used; see I-D.muthu-behave-consent-freshness. </ins> 5.4.
Code change:
I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

Related discussion:
text: 5.6. In a number of cases, it is desirable for the endpoint (i.e., the <del> browser) to be able to directly identity the endpoint on the other side without trusting only the signaling service to which they are </del> <ins> browser) to be able to directly identify the endpoint on the other side without trusting the signaling service to which they are </ins> connected.  For instance, users may be making a call via a federated system where they wish to get direct authentication of the other side.  Alternately, they may be making a call on a site which they
Code change:
I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

Related discussion:
text: identity on a site they do trust (such as a social network.) Recently, a number of Web-based identity technologies (OAuth, <del> BrowserID, Facebook Connect), etc. have been developed.  While the </del> <ins> BrowserID, Facebook Connect etc.) have been developed.  While the </ins> details vary, what these technologies share is that they have a Web- based (i.e., HTTP/HTTPS) identity provider which attests to your identity.  For instance, if I have an account at example.org, I could
Code change:
I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

Related discussion:
text: The precise information from the signaling message that must be cryptographically bound to the user's identity and a mechanism for <del> carrying assertions in JSEP messages. sec.jsep-binding </del> <ins> carrying assertions in JSEP messages.  This is specified in sec.jsep-binding. </ins> The interface to the IdP. sec.protocol-details specifies a specific protocol mechanism which allows the use of any identity