Re: Call for Adoption: draft-meenan-httpbis-compression-dictionary

Hopefully not derailing the adoption call too much but those are great
questions to shake out.

For identifying the dictionary, it's worth noting that the spec requires
that the client advertise a SINGLE dictionary that it supports but yes, the
response depends on the dictionary identified in the request. This also
helps with minimizing the variants that caches would need to store since
the response needs to be varied on the request's available dictionary (and
multiple would explode the permutations).  It wouldn't hurt to echo the
dictionary hash in the response which would allow for other mechanisms of
advertising dictionaries but that also carries the cost of complicating the
vary logic (would need to vary based on whatever request header was used to
negotiate the dictionary that ended up being used).

For the Sec- prefix, it's unlikely that any harm/breakage that isn't
self-inflicted would happen if it wasn't there and it wouldn't
expose private information if it weren't and was abused since the responses
are not opaque but since the dictionary selection and usage is handled
entirely at the transport layer and transparent to fetch there's also
minimal benefit to making it writable from the application code. It's not a
hard requirement though so either way works.

As far as splitting the doc into two, it could make sense since setting the
dictionary in a response doesn't have to be the only way that client's
populate available dictionaries but the dictionary selection is somewhat
entangled with the subsequent request.  There's a good chance that fields
will need to be added to Use-As-Dictionary (I just added "type", for
example, to allow for forward-compatibility with non-raw dictionaries) but
some of those changes will also cascade to the content encoding.
Zstandard-specific or Brotli-specific dictionary formats, for example,
would require new content encodings as well as some explanation for what to
send in the Accept-Encoding when using format-specific dictionaries.

Either way, I think these are all great examples of what the working group
can do to help move the ID's and experiments to a usable RFC that we're all
happy with.

On Wed, Aug 9, 2023 at 10:31 PM Martin Thomson <mt@lowentropy.net> wrote:

> One thing that I forgot: would it be worth considering a split for
> Use-As-Dictionary?  Or do we just need more information?  I have far less
> confidence in that component myself.
>
> If this all stays as experimental, a single document is fine.  However, if
> delta encoding ends up being a slam dunk and we need more information on
> Use-As-Dictionary, then it might be good to take delta encoding as a
> proposed standard and leave Use-As-Dictionary as an experiment.
>
> Cheers,
> Martin
>
> On Thu, Aug 10, 2023, at 11:58, Mark Nottingham wrote:
> > Everyone,
> >
> > Discussion at IETF117 seemed to indicate strong support for, and no
> > significant pushback against, restarting work on dictionary
> > compression, based on this draft:
> >
> >
> https://datatracker.ietf.org/doc/draft-meenan-httpbis-compression-dictionary/
> >
> > So, this e-mail begins its Call for Adoption; please indicate your
> > support or lack thereof (ideally, with reasons). The CfA will end on
> > 2023-08-24 , after which the Chairs will make a determination.
> >
> > Cheers,
> >
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
>
>