Subject: Can we simplify SETTINGS?

From: Ryan Hamilton <[email-masked]>
Date: Fri, 10 Aug 2018 11:07:11 -0700

Howdy,

The SETTINGS frame format is extremely flexible. While the identifiers
(keys) are uint16s (though not encoded as a varint even though most/all
identifiers could be varint encoded as a single byte), the contents
(values) are, on the wire, sequences of bytes of arbitrary length. (Is it
legal/desirable to permit a peer to send a 1GB setting contents?) But more
than that in some cases they are booleans (true if the content is empty,
false if the identifier is missing?!). This is quite a general purpose
representation.

But curiously, there are only two defined SETTINGS and they are both
integers.

Since HTTP/QUIC only needs two numeric settings, it seems like we could
just define the settings frame to be a sequence of pairs of varints (while
still allowing greased identifiers, of course). It seems like that would be
much simpler and would not really cost us anything. But perhaps this has
been discussed previously and there's a use case I'm not thinking about, or
perhaps we have a longer list of settings that we're planning to add to
this list before we "finish" v1?

I can well imaging abusing, sorry I mean using, a SETTINGS frame to carry
all sorts of interesting data of various types. But such data could "just
as easily"(tm) be carried in some application-specific frame type.

Cheers,

Ryan

---

From: Luca Niccolini <[email-masked]>
Date: Fri, 10 Aug 2018 18:26:39 +0000

Ryan,

there is an open issue about this and discussion ongoing on Github
https://github.com/quicwg/base-drafts/issues/1556

Allowing arbitrary data to be carried by an extension frames enabled via simpler settings is one of the proposed alternatives.

Cheers,
Luca

From: QUIC <[email-masked]> on behalf of Ryan Hamilton <rch=[email-masked]>
Date: Friday, August 10, 2018 at 11:08 AM
To: IETF QUIC WG <[email-masked]>
Subject: Can we simplify SETTINGS?

Howdy,

The SETTINGS frame format is extremely flexible. While the identifiers (keys) are uint16s (though not encoded as a varint even though most/all identifiers could be varint encoded as a single byte), the contents (values) are, on the wire, sequences of bytes of arbitrary length. (Is it legal/desirable to permit a peer to send a 1GB setting contents?) But more than that in some cases they are booleans (true if the content is empty, false if the identifier is missing?!). This is quite a general purpose representation.

But curiously, there are only two defined SETTINGS and they are both integers.

Since HTTP/QUIC only needs two numeric settings, it seems like we could just define the settings frame to be a sequence of pairs of varints (while still allowing greased identifiers, of course). It seems like that would be much simpler and would not really cost us anything. But perhaps this has been discussed previously and there's a use case I'm not thinking about, or perhaps we have a longer list of settings that we're planning to add to this list before we "finish" v1?

I can well imaging abusing, sorry I mean using, a SETTINGS frame to carry all sorts of interesting data of various types. But such data could "just as easily"(tm) be carried in some application-specific frame type.

Cheers,

Ryan

---

From: Mike Bishop <[email-masked]>
Date: Fri, 10 Aug 2018 20:57:57 +0000

The short form is that the very flexible format proposal (mine, full disclosure) came out of two observations:

  *   H2 extensions which modify semantics need a Boolean on/off indicator for support.  The core spec doesn’t need this, but extensions are expected to typically be 0/1.
  *   The original incarnation of Secondary Certificates was trying to transfer some fairly complex information in SETTINGS, and trying to coerce that into a fixed integer was problematic.  The original plan was to have a registry-controlled bitmap, in the absence of structured settings.  (Ick!)  Instead, we’ve shoved that complexity into TLS via Exported Authenticators.

Now, will both of these be applicable to HQ?  I don’t know.  Most H2 extensions, but not all, have not been semantically breaking and so don’t need an on/off setting.  No one has yet built an extension that couldn’t be done without the structured settings.

There’s definitely value in having the flexibility – I just don’t have a good feel for the trade-off between the complexity and the applications we don’t know about yet.

From: QUIC <[email-masked]> On Behalf Of Luca Niccolini
Sent: Friday, August 10, 2018 11:27 AM
To: Ryan Hamilton <rch=[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Can we simplify SETTINGS?

Ryan,

Cheers,
Luca

From: QUIC <[email-masked]<mailto:[email-masked]>> on behalf of Ryan Hamilton <rch=[email-masked]<mailto:rch=[email-masked]>>
Date: Friday, August 10, 2018 at 11:08 AM
To: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Can we simplify SETTINGS?

Howdy,

Cheers,

Ryan