Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt

[Victor Vasiliev <[e-mail]>]

This is correct, all codepoints we're currently assigning are
no-dictionary.  Also, since you've asked, we've reserved the 0 codepoint in
the latest version of the draft.

On Tue, Feb 6, 2018 at 10:19 AM, Sean Turner <[e-mail]> wrote:

>
>
> > On Feb 5, 2018, at 13:32, Victor Vasiliev <[e-mail]> wrote:
> >
> > On Fri, Feb 2, 2018 at 9:25 AM, Sean Turner <[e-mail]> wrote:
> >
> >
> > > On Jan 26, 2018, at 05:26, Alessandro Ghedini <[e-mail]>
> wrote:
> > >
> > > Me and Victor would like to ask for early codepoints assignment again,
> if you
> > > think we are ready now.
> >
> > This now on the chair’s list of things to do.  It’s been a week and
> nobody has complained so I’m thinking the draft is on the right track.
>  Got one question before we start the RFC7120-dictated early code point
> assignment dance:
> >
> > Q. What’s the plan for the dictionary?  Is a field going to be included
> later to indicate which one is in use, or is the dictionary going to be
> linked to the extension number and a new one will be minted when the
> dictionary is updated?
> >
> > The plan is to allocate a new algorithm codepoint for each (compression
> method, dictionary) tuple.  I don't want to decouple them, because it turns
> out that for different algorithms the dictionary can be supplied in
> different ways, and thus the actual content for the dictionary may vary.
> >
> > (I'll address the nits a little bit later)
>
> I can live with this approach because it’s better than minting a new
> extension every time.  But just for the record then the code points we’re
> looking to assign now are “no dictionary”.
>
> spt