jiebi/CodeConvo huggingface dataset:
Code change:
The PSK associated with the ticket depends on the client Finished and cannot be pre-computed in handshakes with client authentication.  The NewSessionTicket message MUST NOT include an "early_data" extension. <del> A mechanism by which clients can specify the desired number of tickets needed for future connections is defined in I-D.ietf-tls- ticketrequests. </del> <ins> Servers should take into account that fewer newSessionTickets will likely be needed in EAP-TLS than in the usual HTTPS connection scenario.  In most cases a single newSessionTicket will be sufficient.  A mechanism by which clients can specify the desired number of tickets needed for future connections is defined in I- D.ietf-tls-ticketrequests. </ins> figbase2 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication and ticket establishment of a

Related discussion:
text: According to suggeestion in issue
Alan has suggested that more Profiling / guidance regarding NewSessionTicket would be good. TLS 1.3 allows any number of newsessionticket to be send in any of the server flights. All ways are secure. TLS 1.3 leaves how and when to the TLS implementation.
This is a new request for technical change not related to the IESG DISUCUSS. Based on earlier discussions changes to the TLS layer are likely a bit controversial. John: I don't see what is special with EAP-TLS here. I also don't know what a good recommendation for the TLS layer would be or what can be enforced in TLS implementations. This would likely need interaction with TLS people,
Note also that draft-ietf-tls-ticketrequests is in the RFC Editor's queue and goes into a bit more detail about when different numbers of tickets might be desired (as well as a mechanism to indicate the client's desires, though it's not entirely clear to me whether that will be very helpful for the EAP-TLS usage).
Based on your earlier comment on draft-ietf-tls-ticketrequests, I already added a reference to ietf-tls-ticketrequests in version -14 "A mechanism by which clients can specify the desired number of tickets needed for future connections is defined in [I-D.ietf-tls-ticketrequests]."
Oops, shame on me for not checking. (Thanks for adding the reference the last time I mentioned it!)
I think it would be fine to include a SHOULD send only one NewSessionTicket since EAP clients will typically only need one at a time.
I am not comfortable adding such guidance without a thorough survey of libraries. As draft-ietf-tls-ticketrequests says: "servers vend some (often hard-coded) number of tickets per connection. Some server implementations return a different default number of tickets for session resumption than for the initial connection that created the session. No static choice, whether fixed, or resumption-dependent is ideal for all situations." I know that openssl allows to control number of tickets with URL but I don't we think we can be sure about behavior of all libraries out there. Also some noteworthy text from draft-ietf-tls-ticketrequests: "Especially when the client was initially authenticated with a client certificate, that session may need to be refreshed from time to time.
Code change:
The PSK associated with the ticket depends on the client Finished and cannot be pre-computed in handshakes with client authentication.  The NewSessionTicket message MUST NOT include an "early_data" extension. <del> A mechanism by which clients can specify the desired number of tickets needed for future connections is defined in I-D.ietf-tls- ticketrequests. </del> <ins> Servers should take into account that fewer newSessionTickets will likely be needed in EAP-TLS than in the usual HTTPS connection scenario.  In most cases a single newSessionTicket will be sufficient.  A mechanism by which clients can specify the desired number of tickets needed for future connections is defined in I- D.ietf-tls-ticketrequests. </ins> figbase2 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication and ticket establishment of a

Related discussion:
text: Consequently, a server may periodically force a new connection even when the client presents a valid ticket. When that happens, it is possible that any other tickets derived from the same original session are equally invalid. A client avoids a full handshake on subsequent connections if it replaces all stored tickets with new ones obtained from the just performed full handshake. The number of tickets the server should vend for a new connection may therefore need to be larger than the number for routine resumption."
How about removing the normative SHOULD, something like: desired number of tickets needed for future connections is defined in [I-D.ietf-tls-ticketrequests]. >
This non-normative suggestion sounds good to me.
John's suggested text looks good. By the way, I checked boringssl: URL It seems to issue 2 tickets by default (static const int kNumTickets = 2). As far as I can tell, the only way to limit to 1 ticket is by changing the code manually and re-compiling the library.
This is resolved in PR
Merged PR
Code change:
at the CoAP layer then it may be inclined to use the endpoint name for looking up what information to provision to the malicious device. <del> Endpoint authentication needs to be checked independently of whether there are configured requirements on the credentials for a given endpoint name (secure-ep) or whether arbitrary names are accepted (arbitrary-ep). </del> <ins> Endpoint authorization needs to be checked on registration and registration resource operations independently of whether there are configured requirements on the credentials for a given endpoint name (secure-ep) or whether arbitrary names are accepted (arbitrary-ep). </ins> Simple registration could be used to circumvent address-based access control: An attacker would send a simple registration request with

Related discussion:
text: Authentication alone is never sufficient; with the First-Come-Fist-Remembered policy of , it should be easier to see how this is still authorization. See-Also: URL Thanks for addressing my DISCUSS and COMMENT feedback
Code change:
A function argument is a "filter-path" or a "comparable". <del> According to filter-selector, a "function-expression" is valid as a </del> <ins> According to filter-selector, a "function-expr" is valid as a </ins> "filter-path" or a "comparable". Any function expressions in a query must be well-formed (by

Related discussion:
text: E.g.,
I propose a slightly more compact naming of ABNF of - and -segment, which should be more consistent between them two. is well known from LaTeX and means or there.
above is wrong (and so it is in the current spec). It needs to read ... to not allow triple dot ( :-)
NAME Wouldn't dotdot-wildcard etc. be less cryptic?
Here are some quibbles with the current ABNF (prior to PR being merged) which we can sort out after The Great Renaming:
Yes, yes. See. Fixed in I like the way this looks like now. Maybe I don't understand; can you elaborate? Fixed this (and following) in Removed in To be fixed in overall overhaul, next Yes! To be fixed in overall overhaul, next To be fixed in overall overhaul, next Fixed in Discuss this in its own issue, I'd say. Fixed in It certainly does not -- it is the subset that is actually needed for normalized paths. To stay normalized, we don't allow random other ones.
Of course ... I'm quite dispassionate here.
Please see my proposal in
With merged, we still have the expression cleanup the separate issue (enhancement) whether should be allowed, to mean
My remaining points are covered by PRs , , and .
Shouldn't be named according to all other above ?
Yes, I agree. See URL
NAME Are we ready to close this issue now the PRs have been merged or did you have more expression cleanup in mind?
The only thing that comes to my mind is standardizing on the column where the is -- this is currently rather chaotic. But that can be a new issue.
Indentation of : number of lines such indented
(And it doesn't need to be consistent, just a bit less chaotic.)
Let's make the a new issue. (I haven't got a good feel for the optimal solution.)
Before we close this issue, URL slipped through the net in my earlier PRs.
Then could resolve to either or . We would introduce an ambiguity, we already found with Json Pointer () ...
OK, with the latest blank space realignments that are part of (5e2cc85), I think we are done with this.
Thank you!
Code change:
A function argument is a "filter-path" or a "comparable". <del> According to filter-selector, a "function-expression" is valid as a </del> <ins> According to filter-selector, a "function-expr" is valid as a </ins> "filter-path" or a "comparable". Any function expressions in a query must be well-formed (by

Related discussion:
text: ... or do we need two selectors here (Ch.2.61) child-longhand = "[" S selector 1(S "," S selector) S "]" given that '1' means 'at least one'.
Code change:
these are used to define "!=", "<=", ">", and ">=". When either side of a comparison results in an empty nodelist or <del> "Nothing": </del> <ins> "Nothing" (see typesys): </ins> a comparison using the operator "==" yields true if and only the other side also results in an empty nodelist or "Nothing".

Related discussion:
text: NAME Deleting the text should have addressed your original editorial issue. This PR also adds the missing cross-reference. If you're happy, please approve.
Code change:
the following additional information MUST be provisioned to both parties: <ins> The TLS version number for use with this PSK </ins> The cipher suite for use with this PSK The Application-Layer Protocol Negotiation (ALPN) protocol, if any

Related discussion:
text: The 0-RTT key might differ between TLS versions (as demonstrated with the draft -20 changes). Be explicit about storing this version number since section 4.2.9 requires this information too.
Code change:
11.3. The following registrations are done following the procedure <del> specified in RFC6838 and RFC7303. </del> <ins> specified in RFC6838 and RFC7303.  Clipboard formats are defined for the JSON and XML form of lists but do not make sense for streams or other formats. </ins> Note to RFC Editor - please remove this paragraph.  Note that a request for media type review for senml+json was sent to the media-

Related discussion:
text: See email from paul L Nov1 to media-types Hello Cullen, it seems to me that all the content-types you have been describing about senML are candidate content types to be exchanged over the clipboard of a normal mobile or desk computer; e.g. from a reading app to another, … Do you agree on this? If yes, then I’d like to recommend to add: MacOS Uniform Type Identiers Windows Clipboard Name for each of the content-types. If there is earlier experience in this realm, probably this should be taken, otherwise, I can probably suggest some clipboard names. Standardising such at the Media-Type declaration level allows to set a reference frame so that other implementations can follow, just as the content-type name. For examples of including this in the media-type registration, see that of SVG or MathML. thanks in advance. Paul
At IETF 97 was "probably should do this" - see URL
See MathML at URL
On the UTI, currently only apple can declare ones in the public space ( see URL ). I do not see how to request one. There is a bunch of extra info apple would need to add to the OS to really make this work outlined in URL
Windows clipboard info at URL(v=vs.85).aspx
Makes sense; no need for a clipboard format for the streaming and compressed versions actually.
Code change:
increased cost (depending on whether the application chooses to use TURN). <del> The exact impact of this technique is being researched experimentally and will be provided before publication of this document. </del> <ins> One potential mitigation, as discussed in {#privacy}, is to not conceal candidates created from RFC4941 IPv6 addresses.  This permits connectivity even in large internal networks or where mDNS is disabled. The exact impact of the mDNS technique is being researched experimentally and will be provided before publication of this document. </ins> 4.2.

Related discussion:
text: I think this is good to go, will plan to land at EOD.
Does it obfuscate, conceal, or obscure local IP addresses? My vote is for conceal.
Conceal/concealment sgtm.
As noted in , we don't need to use the same term in every case, but the terms should have the same meaning. conceal and hide are fairly synonymous, but conceal and obfuscate have slightly different meanings.
This section is largely normative, so it might make more sense to put some parts from it immediately after Principle, namely the various adjustments to the technique that need to be considered (TURN, IPv6, stats) Things where we merely provide discussion (e.g., session monitoring) rather than normative guidance could remain in the privacy section.
Due to their different sensitivity and lifetime.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private?
Code change:
increased cost (depending on whether the application chooses to use TURN). <del> The exact impact of this technique is being researched experimentally and will be provided before publication of this document. </del> <ins> One potential mitigation, as discussed in {#privacy}, is to not conceal candidates created from RFC4941 IPv6 addresses.  This permits connectivity even in large internal networks or where mDNS is disabled. The exact impact of the mDNS technique is being researched experimentally and will be provided before publication of this document. </ins> 4.2.

Related discussion:
text: If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
The rest LGTM
Code change:
The ACK_MP frame, as specified in ack-mp-frame, is used to acknowledge 1-RTT packets.  Compared to the QUIC version 1 ACK frame, <del> the ACK_MP frames additionally contains a Packet Number Space Identifier (PN Space ID).  The PN Space ID used to distinguish packet number spaces for different paths and is simply derived from the sequence number of Destination Connection ID.  Therefore, the packet number space for 1-RTT packets can be identified based on the Destination Connection ID in each packet. </del> <ins> the ACK_MP frame additionally contains a Path ID.  The Path ID is used to distinguish packet number spaces for different paths and is simply derived from the sequence number of Destination Connection ID. Therefore, the Path ID for 1-RTT packets can be identified based on the Destination Connection ID in each packet. </ins> Acknowledgements of Initial and Handshake packets MUST be carried using ACK frames, as specified in QUIC-TRANSPORT.  The ACK frames, as

Related discussion:
text: From PR from NAME
Let's do another editorial pass and evtl. some re-org first and then address this issue. I think we all already agreed that we only need one of the two. So we only need to decide with name we keep.
I prefer to use the name "Path ID", as it is more intuitive in the context of multipath.
The conflict was solved. LGTM.Sounds good.
Code change:
MTUs can vary.  TODO: Describe how the path MTU can be computed, specifically propagation across HTTP proxies. <del> 4.5. </del> <ins> 4.4. </ins> In WebTransport over HTTP/3, the client MAY send its SETTINGS frame, as well as multiple WebTransport CONNECT requests, WebTransport data

Related discussion:
text: This matches agreement at the last interim. We should separate this into a different draft, but for now this will make the draft match implementation.
Partially addresses . cc NAME NAME
Http3Transport currently assumes that server-initiated bidirectional streams and datagrams can only be used for WebTransport. I suggest we prefix each server-initiated bidirectional stream and datagram with a new HTTP/3 frame type for WebTransport. This way, a future standard could define it's own frame type to run alongside WebTransport.
Using an H3 frame type for server initiated bidi streams would also make the design more consistent, instead of the asymmetric design there is today. It costs a byte per bidi stream, but it seems worth it for consistency and flexibility. For datagrams, I believe that we'd want to be able to coexist with other H3 extensions, such as MASQUE, and I believe that's possible without any extra overhead by adding a Session -> Datagram flow ID mapping when a WebTransport session is created.
If it's a single byte, it's more of a stream type (like the unidirectional stream-type) than a frame type, right? There's a discussion Victor pointed me to in , where it's suggested that datagrams belonging to a WebTransport session use the Flow ID = to the Session ID. It would be nice to avoid the extra state and lookup.
Ah yes, it's more of a stream type. In that case, I'm unsure of whether there's a good way of eliminating the asymmetry. The only option I can think of is to not use a stream type for server bidi streams and only use the frame, like for the client initiated bidi streams? Thanks for the pointer to , it looks like there are a few potential designs for datagrams flow IDs. If in doubt, simpler is probably better. I'll think more about this one.
I agree we should use the same mechanics for client and server bidi streams.
After thinking about this more, not having a stream type doesn't seem so bad to me and it does provide symmetry. Stream types seem like an obvious design choice, but I believe HTTP/3 is sufficiently constrained that one could infer the stream type based on the first frame on the stream. For example, the control stream MUST start with SETTINGS.
Code change:
MTUs can vary.  TODO: Describe how the path MTU can be computed, specifically propagation across HTTP proxies. <del> 4.5. </del> <ins> 4.4. </ins> In WebTransport over HTTP/3, the client MAY send its SETTINGS frame, as well as multiple WebTransport CONNECT requests, WebTransport data

Related discussion:
text: In retrospect, having both stream types and frame types is a bit awkward, and it likely would have been cleaner to only have frame types, but that ship has sailed.
After having implemented this for hackathon, I can confirm that the lack of stream preface on server-bidi streams is annoying and requires special casing (I actually simulate receiving one). Let's please add one. I took a bit of a shortcut and treated the stream preface as both a stream type AND a frame type. After peeking at the unidirectional stream input to discover that it's WT, I let the parser run on that and treat it as a frame type, making it symmetric with the bidi case. Is it possible to define a reserved frame type with the same value as the stream type?
Given HTTP/3 does not have a stream type varint for bidi streams, I think a potential way forward is to say that the first frame on the bidi stream can indicate the 'type' of the stream, but that there is no explicit type identifier on the wire. Feel free to ignore the below comment, as it's apparently unchanged from January Looking back, SETTINGS is required to be the first frame on the control stream, so the control stream type is a bit redundant and the same is true for QPACK and I believe could be true for server push? Obviously we're not going to redesign HTTP/3 stream and frame types at this stage in the process, but making bidi streams consistent for both perspectives seems preferable to me.
Discussed at IETF 110. There seems to be a general agreement that we should make server-initiated bidi streams use the same encoding as client-initiated ones (that is to say, frames). There was some interest expressed in splitting definition of server-initiated bidi streams into their own draft; NAME and NAME are to reach out to httpbis about the appropriate venue for that.
Just bringing some of the discussion from here: HTTP should provide some consistent guidance for the format of HTTP/3 extension streams. Client-bidi extension streams have to start with a frame or series of frames, to be compatible for H3. One of these frames has to identify the type of stream. This is how WT is currently specified.
Code change:
MTUs can vary.  TODO: Describe how the path MTU can be computed, specifically propagation across HTTP proxies. <del> 4.5. </del> <ins> 4.4. </ins> In WebTransport over HTTP/3, the client MAY send its SETTINGS frame, as well as multiple WebTransport CONNECT requests, WebTransport data

Related discussion:
text: Unidirectional streams all start with a Stream Type, but after that are inconsistent in H3 the control stream is: Stream Type + Frames QPACK Streams are: Stream Type + QPACK instructions Push streams are: Stream Type + Preface (Push ID) + Frames Stream Type seems like a more general extension mechanism, since it can be used to completely decouple from HTTP/3 frame parsing.
I find stream types to be less extensible than frames: frames allow you to do anything that stream types do, while additionally providing more opportunity for extensibility. I would prefer server-initiated bidirectional streams to behave like client-initiated bidirectional streams instead of unidirectional streams, as that makes implementations simpler.
January Me said: So I think I'm arguing against myself and I'm going to stop. My other comments on this thread we that I didn't like was the asymmetry of WT uni streams, which currently are . My past self seemed to be advocating that we change WT uni streams to or perhaps . Do we want general guidance about how extensions should use Stream Type vs Frames on unidirectional streams -- specifically that there should be at least one frame?
The place to put that guidance would have been draft-ietf-quic-http, and I think that ship has sailed. For unidirectional streams, I like your framing proposal as that enables extension frames down the road.
Well, not too late to put out a BCP or something, especially if there's going to be some kind of formal guidance on server-initiated bidi streams. I'll open a separate issue about changing the WT uni framing.
I think this specific issue was fixed by . Please reopen if I'm wrong.
Code change:
The Stream Cipher CID algorithm provides cryptographic protection at the cost of additional per-packet processing at the load balancer to <del> decrypt every incoming connection ID.  The CID format is depicted below. </del> <ins> decrypt every incoming connection ID. </ins> 5.2.1.

Related discussion:
text: The CID format figure has been removed since draft-ietf-quic-load-balancers-08