jiebi/CodeConvo huggingface dataset:
The WebRTC spec was designed to be Peer-to-Peer - so it makes sense that both sides need equal capabilities since you never know who will initiate an offer - so mandating actpass in the offer is a good idea. WISH/WHIP is explicitly client-server so asymmetry is to be expected. I would argue that the original wording is wrong however - "WHIP endpoint MUST use a setup attribute value of setup:passive in the SDP answer." Should read "WHIP endpoint SHOULD use a setup attribute value of setup:passive in the SDP answer. Or if it does not support passive it MUST reply with an http 402 error status and an explanation error message."
I think it shall be MUST. If the server cannot do that for whatever reason it will obviously have to return an error. We can for sure specify which error code to use. Also, I think it is better to say that the server MUST follow the procedures in RFC 4573. Regarding the WHIP client, a compromise would be to say that it SHOULD use actpass, according to 4573, unless it only implements the DTLS client role in which case it can use active. Because, we should not forbid a WHIP client from using the standard 4573 behavior if it is able to do so. In addition, there could be a note saying a few words about why a WHIP client might only implement the DTLS client role.
Here is some new text suggestion (I have not created a PR yet) for Section 4.2. Note that I also modify the BUNDLE text. The SDP BUNDLE mechanism [RFC8843] MUST be used by both WHIP clients and media servers. Each m- line MUST be part of a single BUNDLE group. Hence, when a WHIP client sends an SDP offer, it MUST include a bundle-only attribute in each bundled m- line. In addition, per [8843] the WHIP client and media server will use RTP/RTCP multiplexing for all bundled media. The WHIP client and media server SHOULD include the rtcp-mux-only attribute in each bundled m- line. When a WHIP client sends an SDP offer, it SHOULD use the setup:actpass attribute, as defined in [RFC5763].
However, if the WHIP client only implements the DTLS client role, it MAY use the setup:active attribute. NOTE: [RFC5763] defines that the offerer must use the setup:actpass attribute. However, the WHIP client will always communicate with a media server that is expected to support the DTLS server role, in which case the client might choose to only implement support for the DTLS client role.
I like that and I think it is a good compromise, creating the PR now
I have split it in two PRs so we can review/merge them independently: BUNDLE: URL SETUP: URL The include the proposed changes by NAME with a bit of rewording to match the notation of the referenced RFCs, and include that the server SHOULD response with a 422 error if the setup:active is not supported.
When reading this again, I think there still need to be some changes: both the WHIP endpoint and the media server need to support BUNDLE/multiplexing: the WHIP endpoint needs to support the BUNDLE SDP extension, while the media server needs to support the multiplexed media associated with the BUNDLE group.
After discussion with NAME , this PR now makes keys single-format-only as previously suggested.
To edit notification comments on pull requests, go to your ._
Yaron: why are we sending a JWK as well as a cert? Are we checking that the cert contains the same public key as the cert? Justin: I would be OK with the different formats being mutually exclusive somehow. The AS would need to check that they’re the same and throw an error if not. But this would also let the RC send over whatever it’s got for its own keys every time.
The document has been changed to address this issue, copying my text that refers to the latest draft version: In Sec. 7.1 we allow the client to include multiple keys of different formats, provided they are "equivalent". This doesn't make sense, because the only reason to send multiple keys is that the sender suspects that the recipient doesn't understand one of the formats. But if that's the case, the recipient is not able to validate the MUST requirement that the two formats be equivalent. This could also lead to interesting key injection attacks. IMO we should only allow one key value/format for each request.
Does this make sense outside of a protocol-specific context? I am aware that this is a different can of worms adding protocol specific parameters to clone, but this looks like a strange concept to add an Integer here that may have different side effects in QUIC and SCTP…
That's a very good question. This feature request came up in the QuIC mapping part of the discussion in Vienna, see: URL Not sure what to do: keep it as it is, remove it, or add the protocol: assign: "if protocol = x, then stream ID = y" read: "stream ID is y, and your protocol is x" I have to say, I don't like this particular way, as it would complicate matters quite a bit. But how else to do it?
All of the multistreaming protocols we know about have an integer stream identifier. I suppose a future protocol could use some sort of binary blob for identifying streams (which are... pedantically... representable as arbitrary-length integers)
Interim discussion: let's make Clone() and Initiate() take a group of protocol-specific parameters (optionally) which allow protocols like QUIC and SCTP to extend this.
I just made a very minimalist update, where "protocolSpecificProperties" is only a parameter of Clone(). Why not list it as readable properties, and why not as a parameter of Initiate, as we discussed? What's the point of saying "there can be protocol-specific properties which are currently not defined, and they can be readable"? This is for a future spec to say, when it proposes a new transport property. Regarding Initiate(), I think this should in fact not be a parameter to the Initiate Action itself, but a transport property to be supplied when creating a Preconnection. Again, this made me find that I would only write something like "There can also be transport properties that are not yet defined", which doesn't seem to be useful text. In conclusion, I found that only the Clone() Action needs this as a new parameter. Everything else is for future mapping documents. Thoughts?
Many thanks! I incorporated your suggestion, and made a tiny edit to it (behaviour => behavior, underlaying => underlying, and "stream or connection" instead of "stream/connection").
... combined with "if the transport is mux'ing, else ..."
Thanks – I guess we have a fairly good solution.
draft-ietf-quic-tls currently mentions AEADAES256CCM, however there is no way to use that AEAD in TLS 1.3 - TLSAES256CCMSHA256 does not appear in the . If I understand this correctly, the presence of AEADAES256CCM in the document was an editorial oversight.
Thanks. This was extremely confusing: you meant CCM, but wrote GCM in tons of places.
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.
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.
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.
Thanks to Felipe Gasper for .
Merging despite spurious CI failure, since it seems pretty clear that the CI failure is spurious. Hi all, Draft 16 has this: An ACME client MAY attempt to fetch the certificate with a GET request. If the server does not allow GET requests for certificate resources, then it will return an error as described in Section 6.3 . On receiving such an error, the client SHOULD fall back to a POST-as- GET request. From what I can discern from this list’s most recent posts on the topic, I’m under the impression that plain GET for certificates is not to be part of the principal ACME spec; should the above, then, be removed? -FG
sec 4.2.2 "implementations MUST provide a method for the application to determine the entire set of possible values for each property." Is this meant to be a requirement for a machine-readable API for learning the enum, or merely a requirement for documentation? i.e. is it satisfied if the values are in the man page or comments of the C header file?
As a by-note, isn't this a great place to use "REQUIRED" and say whether it is required to specify or required to support :-).
Proposal: Just remove "however, implementations MUST provide a method for the application to determine the entire set of possible values for each property." This is too implementation- and language- specific.
Consider a client that does Since the ICE gathering process has started at the time of , it is too late at this point to call . Thus, a way is needed to find the set of ICE servers before the offer is POSTed to the server. In his mail of 12 July 2022, Sergio suggests a different procedure: This alternate procedure should work, but it is somewhat unusual; thus, the spec should describe this procedure in detail, and indicate that this is the procedure that the WHIP client must use if it wishes to use the server-provided ICE servers. What is more, with this procedure the posted offer does not contain any local candidates, which might imply that client-side Trickle ICE is a requirement, at least in some environments. Again, this should be discussed in the draft.
That is not true. If server is on a public IP address or behind a port forwarding NAT. The candidates sent by the server are enough to establish the ICE connection. Gathering all the ICE candidates on the local offer are only required if the client does not support trickle and the server is behind of a NAT that requires hole punching. I don't think we should explain how to use webrtc apis in the spec.
So WHIP is restricted to the case where the server is on a public IP, with no firewall? That would be fine with me, but if that's the case then IMHO it needs to be stated explicitly in the draft. What happens if the client is on a restrictive network that only lets outgoing TCP through, which is unfortunately still the case in many university networks? Are you assuming that the server supports passive TCP ICE? If so, should that be mentioned in the draft somewhere?
The turn server configuration via OPTIONS is not going to be removed. I can add a note like:
This is to partially
In section 4.2 there is a list of "places an attesting environment can exist" that is limited. The text should be softened to say the list is only examples and there is no formal limitation or requirement on the security of an Attester. There should probably be a detailed description of Attester security in the document, but it should be in Security Considerations. This seems like a glaring omission from Security Considerations.
The considerations weren't the extent of the issue. There is still text in 4.2 that I think needs changing.
As proposed on list.
Hanno Becker points out that the current text does not cryptographically protect the CID when we have coalesced packets. I created PR to add this feature, but I think instead we should simply require that all packets have CIDs once the CID is established. This seems like a net reduction in complexity. There would be two changes here: Re-emphasize the point already in the DTLS CID spec that you abort if a CID is expected and none is found. Remove the text about allowing implicit CIDs.
NAME NAME
This was resolved by . Please re-open if that's not the case!
This is a proposal by Gorry to address issue
This works for me.
Should TAPS be cited as an informational ref to an API that is being discussed by the IETF, and which could apply to QUIC - at least to define the primitives needed in an API, and has quite some insight into protocol racing/fallback as described in applicability?
I'd be happy to do so ;-) however we avoided in the end to talk to much about specific of the interfaces or needed nobs. So not sure it fits or where to fit it.... where would you want to say something?
I think the WG should consider writing a short section on this. It's important enough that we have a WG developing relevant specs for how to build APIs and the need for this type of fallback/racing.
I'm not sure the QUIC WG has enough experience to say anything on the matter. The fallback discussion is about how (Application Mapping + QUIC) could fallback to (alternative application mapping + TCP). For HTTP/3 this isn't a straight fallback - if QUIC fails then a different HTTP version over TCP is required. This has consequences for applications that use HTTP/3 as a substrate (MASQUE, WebTransport) which rely on features only it provides like unreliable DATAGRAM. I think the Applicability spec might need to say more here. What I'm trying to highlight is that there isn't a straight shootout between TCP and QUIC. If TAPS frames things like that then I don't know that it helps Applicability.
taps allows you to use the same interface for multiple transports and also provides you a way to state requirements (hard or soft) to restricts the selection of possible transports. In that sense for some application TCP and QUIC might be not make a real difference as long as all features requested are support, e.g reliability and in-order delivery. Still not sure what/if we want to say something in applicability statement...?
NAME we were trying to not focus on http in this document. But I do agree that the fact that there is a different version needed for http to fallback could still be interesting. How about adding as sentence like the add the end of the first paragraph in section 2: OLD In the case of HTTP, this fallback is TLS 1.3 over TCP.
NEW In the case of HTTP, this fallback is TLS 1.3 over TCP. Note that for HTTP a fallback to TCP also requires the use of a different version of HTTP, as HTTP/3 has been optimised for use with QUIC, e.g., by removing multiplexing from the HTTP layer and used the provided mechanism within QUIC. We could even add something more like: "Other applications that are optimised for QUIC might need similar adaption in order to be able to function on TCP." However, not sure that adds much... What do you think?
I'm still not sure that helps. And I'm trying not to derail Gorry's OP. The main grounding I have in my understanding is HTTP. But I appreciate the Applicability document is general purpose, so apologies. Many HTTP applications operate at the semantic level. HTTP semantics are version-independent and get profiled into versions that have a wire-syntax, which depends on different properties of a transport. This could be an optimised use of QUIC features, or it could be an outright requirement for those features. There isn't an interoperable notion of "I want to do HTTP/1.1 over a reliable in-order transport, TAPS selected QUIC for me, great I'll use that" nor "I want to do HTTP/3 over a reliable, multiplexed, in-order transport, TAPS selected SCTP for me". The transport fallback behaviour for HTTP semantics is quite straightforward. Pick a different HTTP version. This could lend itself to a race like scenario. However, there are applications that use HTTP as a substrate and things like MASQUE and WebTransport place requirements on the use of features only available in HTTP/3 - I doubt anyone will try to backport features of QUIC to TCP in order to satisfy the requirements of layers above.
I was thinking of something like: /The IETF TAPS specifications [URL] describe a system in which multiple protocols can be provided below a common API. and describe some of the implications of fall back, which specifically precludes fallback to insecure protocols or to weaker versions of secure protocols. / Perhaps inserted after this: /These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the fallback protocol./ ... and before mentioning fallback to TLS over TCP.
NAME you are right that QUIC provides features that TCP doesn't provide and if you use those features you cannot just straight-away replace one with the other. However, a simple one-to-one replacement not implicated when talking about falling back. Rather than trying to back-port features to TCP, what you need to do is implement that feature in your application instead (as H2 does for multiplexing). But this is also true if you try to use TCP and fall back to UDP but need reliability; then you have to implement it in the application layer. I was trying to be brief in my proposed text and maybe the word "optimise" is not the right one. We can of course say more. Do you want to give it a try and propose some text if you think it would be helpful to say more?
Thanks. I'll have a think on some text. The important thing is that H2 wasn't designed as a fallback for H3, it is its own thing. There are few features that an application desires that it couldn't also achieve by just using HTTP/1.1 and multiple connections for multiplexing.
May I ask what these features are? E.g., the ability to send unreliable datagrams should not matter in the best effort Internet (reliable transfer, when not needed, is just slower). In RFC 8923, we made an effort to identify exactly what MUST be exposed to an application because there's no such fall back. This covers TCP, MPTCP, UDP, UDP-Lite, SCTP and LEDBAT; alas, it excludes QUIC, since this work pre-dates its finalization (by far, despite the date: it spent a long time in the RFC Editor queue). So now I'm curious what QUIC adds to this list.
mainly multiplexing I would say but that probably covered by SCTP
The main feature that QUIC provides to the HTTP substrate is that it is a secure transport that can work on the Internet and is easily integrated with WebPKI. These are meta-features in a way. Having parity of the deployment and security models allows more straightforward rationalisation when designing applications and e.g. Web APIs on top of this substrate.
Thanks! About muxing: is a certain prioritization behavior guaranteed (not just a wish) when muxing with QUIC?