[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]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.