Of course, at some point it starts to make sense to do RLE.
-Ekr
On Wed, Mar 27, 2019 at 6:43 AM Martin Thomson <m...@lowentropy.net> wrote:
> Why not go all in - make this a byte string and start from 0x80 in the
> first byte. When we define the 9th flag, we add another byte. Then you
> have up to 2040 flags (though it might pay to split the space before that).
>
> struct {
> opaque<1..255> flags;
> } Flags;
>
> Otherwise, the first adopter of this pays 10 bytes where they would
> previously have paid 4. Obviously there is a network effect at the third..
> Since I'm writing a draft that will aim to depend on this, I have a vested
> interest in using this.
>
> If you wanted to make it more attractive to me, then maybe porting some of
> the existing flags across might make it more appealing.
>
> On Wed, Mar 27, 2019, at 13:08, Yoav Nir wrote:
> >
> >
> > > On 27 Mar 2019, at 12:26, Daniel Kahn Gillmor <d...@fifthhorseman.net>
> wrote:
> > >
> > > On Wed 2019-03-27 10:52:20 +0100, Nikos Mavrogiannopoulos wrote:
> > >> Right. What about defining a set of extensions (e.g., 2 extensions) of
> > >> flags as:
> > >>
> > >> struct {
> > >> uint64 flags;
> > >> } Flags;
> > >
> > > If we're going to be doing this kind of bit-shaving, this is the way to
> > > go, starting with a single CommonFlags extension -- and maybe even a
> > > uint32 or uint16, with the bitfield registry under tight WG control. If
> > > we exhaust that space, then we just define a CommonFlags2 extension.
> > >
> > > If someone wants an experimental boolean extension to play with, they
> > > can always use an empty extension. They can apply for a bit in
> > > CommonFlags if they find that the compactness is warranted.
> > >
> >
> > OK. You got me convinced.
> >
> > In the spirit of revising quickly and revising often, I’ve uploaded
> version -01:
> >
> > HTML: https://datatracker.ietf.org/doc/html/draft-nir-tls-tlsflags
> > DIFF: https://www.ietf.org/rfcdiff?url2=draft-nir-tls-tlsflags-01
> >
> > Yoav
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
