Let me give two answers -- one a crypto answer and the other a
standards answer.
[de-lurks]
Jon, it seems like you're saying "since this is a purely normative
document we can be as extensive as we want, and there are good reasons
for purely normative documents to be extensive."
The presence of an algorithm in the spec tends to create pressure on
implementations to support that algorithm. When RFC2440 had reserved
entries for TIGER192, there was a small but vocal crowd in the GnuPG
community crying out, "we need TIGER192, it's in the spec!" And as soon
as TIGER192 was removed, those voices died out -- because hey, it's no
longer in the spec.
I am completely and vigorously in favor of OpenPGP retaining the ability
to be agile with respect to algorithms. (In fact, I'd like to see more
work go into this.) But with respect to adding new reserved numbers,
due to the tendency of users to see the spec as prescriptive rather than
normative, I'd like to see us be more conservative.
Also, on a somewhat tangential note -- for more than twenty years we've
been talking off and on about a prescriptive OpenPGP RFC, one that would
focus on what was a good idea as opposed to what was strictly legal.
We've never done it. I'd like to see that change.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp