dkg
commented
1 year ago I should note that the original version indicates that the default display hint was text/plain; charset=iso-8859-1.
for all its idiosyncrasies, parochialism, and other faults, iso-8859-1 has at least one thing going for it: every octet string is a valid iso-8859-1 string. utf-8 does not have this property. This means any attempt to validate octet strings within S-expressions on the basis of their type will now have a failure mode for any unhinted octet string, where no failure mode existed before.
d3e3e3
The main place i encounter s-expressions today is in GnuPG's private key store, in
~/.gnupg/private-keys-v1.d/*.key. These contain raw octet strings for secret key material (in some cases, for encrypted secret key material).According to the text of this document, those octet strings should be assumed to have a default "display hint" of
text/plain; charset=utf-8. However, they are clearly not valid UTF-8 text strings. Concretely, some of these large binary integers contain octet sequences that simply are not valid UTF-8.What does it mean to tell the implementer that an octet string is UTF-8-encoded text when it is not? This seems basically wrong.