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
