Re: [TLS] TLSFlags ambiguity

Oh, perfect! I was trying to find the GitHub repo to make the PR but missed it somehow. Here's a PR: https://github.com/tlswg/tls-flags/pull/37 On Mon, Mar 18, 2024 at 5:01 PM Sean Turner wrote: > I just threw in a couple of PRs to align this I-D with 8446bis & 8447bis, > but forgot to add this

Re: [TLS] TLSFlags ambiguity

I just threw in a couple of PRs to align this I-D with 8446bis & 8447bis, but forgot to add this issue. I have corrected this now so that we won’t forget again: https://github.com/tlswg/tls-flags/issues/36 spt > On Mar 17, 2024, at 13:53, David Benjamin wrote: > > Did this ever get

Re: [TLS] TLSFlags ambiguity

Please see RFC 1700, the section on data notation. The most significant bit in a byte /octet or word is always bit 0. A collection of bytes representing a set of bits should number from 0 or 0x80 hex as a mask for the first byte. While 1700 was obsoleted by the protocol registries, I believe

Re: [TLS] TLSFlags ambiguity

Did this ever get resolved? I noticed that there was a draft-13 cut, but the issue Jonathan pointed out was still there. Looking at Section 2 again, it's actually even goofier than the original email suggests. Section 2 first says: > The FlagExtensions field contains 8 flags in each octet. The

Re: [TLS] TLSFlags ambiguity

Nice catch! I agree those don't match. I think bit zero should be the least-significant bit. That is, we should leave the examples as-is and then fix the specification text. Ordering bits MSB first doesn't make much sense. Unlike bytes, there is no inherent order to bits in memory, so the most

[TLS] TLSFlags ambiguity

Hi TLSWG, I'm working on implementing the TLS Flags extension , and I just wanted to clarify a potential ambiguity in the spec. In Section 2 the spec says: Such documents will have to define which bit to set to show support, and