Subject: Re: [quicwg/base-drafts] HTTP SETTINGS: define setting content encoding (#1556)

From: Mike Bishop <[email-masked]>
Date: Tue, 07 Aug 2018 16:29:38 +0000 (UTC)

That could be specified in four bits, true.  I could be convinced that cutting a byte off the length for every setting value saves more than being able to omit the value for booleans.  The original reason for having an arbitrary-length field was extensions that needed to supply a large set of supported values, such as supported signing algorithms for the CERTIFICATE_PROOF in the originally-adopted version of Secondary Certificates.  So the goal was not only to save bytes from settings that didn't need four bytes, but also to provide extra bytes to settings that needed complex, structured values.

However, the need to negotiate such complicated items has been delegated to TLS in that instance and hasn't shown up elsewhere.  We might simply say that if the need crops up for some future extension, they'll need to define an additional frame type to carry that configuration data.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1556#issuecomment-411119031

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Aug 2018 18:33:50 -0700

That would be a regression in my view.  There is value in having settings being able to express things other than numbers.  The fact that length is redundant is a consequence of that feature, so it doesn't bother me in the slightest.

Here's an example that might make sense, though I doubt that I would implement it... a setting that included a base URL so that request targets could be identified relative to that URL if desired.  That might be justified on the basis that we can't compress parts of header fields (for good reasons), but that particular tweak is probably safe.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1556#issuecomment-411254957

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 08 Aug 2018 07:21:02 -0700

I think there is merit in making SETTINGS simple numerical values, arising from lack of compelling argument otherwise. 

Are use cases that would like more forms of expression really going to be satisfied with an unmodifiable SETTINGS value?

> Here's an example that might make sense, though I doubt that I would implement it... a setting that included a base URL so that request targets could be identified relative to that URL if desired.…

This is curious example but I'll bite. You could achieve the same by defining an extension, enabled by a new numerical SETTINGS value, that articulates the base URL in a new extension frame. 

To take this to an extreme, we could imagine a request group concept *cough* where a set of requests are linked to a particular base URL via stapling to this extension frame. The base URL can be modified through the lifetime of the QUIC connection if needs be. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1556#issuecomment-411422898

---

From: ianswett <[email-masked]>
Date: Sun, 26 Aug 2018 05:08:46 -0700

I agree with Lucas, I'd prefer simple numerical values given that's all we're using in v1.

One could negotiate an extension later to enable other values once/if we have a clear idea of what those are, but I tend to think it'll never be necessary.

Besides complexity, I'm a bit worried implementations will naively parse the settings into a map in memory and then use them.  Given the value is virtually unbounded in length, this could go quite badly.  Admittedly, that would be a poor design, but it's not even possible if every setting value is a number.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1556#issuecomment-416034401