[openpgp] Re: Fwd: I-D list for Open Specification for Pre tty Good Privacy notification: Changes to draft-gallagher-openp gp-code-point-exhaustion
Heiko Schäfer <[email protected]>
| Newsgroups | gmane.ietf.openpgp |
|---|---|
| Message-ID | <[email protected]> |
Hello Justus, list, On 3/20/25 10:57 AM, Justus Winter wrote: > Further, the proposed solution (for which reserving one bit now is the > precondition, so I think it is fair to also consider it), seems to > complicate parsing (and there is precedence on how OpenPGP very cleverly > encodes things like packet body lengths, S2K hash counts, S2K mechanism > type, AEAD block sizes), and I like parsing to become simpler, not more > complicated. I tried to be clear, but will try to be even clearer: I didn't mean to say that I'm in favor of ratifying the specifics of the proposal. I *am*, however, in favor of *just* reserving code points >= 128 (where applicable), until further notice. Reserving a range of code points, by itself, certainly wouldn't complicate any parsing. It would only clarify a policy for how the WG assigns code points, over the next few cycles of extensions. Reserving the upper halves *for now* wouldn't in any way stop the WG from deciding (say, 5 years from now) that it is, after all, the lesser evil to just assign code points >=128 in one-byte representation. (Fwiw, I currently lean towards agreeing with you - I expect to favor avoiding the complexity of Andrew's proposal, myself. But maybe in 5 years my view will have changed. I expect we will collectively gain new insights about the appropriate future evolution of the format, as OpenPGP hopefully flourishes.) Either way, I don't anticipate any urgency (say, on a scale of less than 5 years) to decide how to allocate the upper half of code point spaces, one way or the other. If and when such urgency arises, the WG can deliberate based on all available information at that future point in time. Heiko _______________________________________________ openpgp mailing list -- [email protected] To unsubscribe send an email to [email protected]