On Mon, 2015-03-16 at 23:48 -0700, Jon Callas wrote:
ASCII armor ends up being a nice way to encode something so you don’t
have to play "guess the binary format."
But isn't that basically the same case as with the character encoding
thread?! In the sense of:
It's not OpenPGPs task to fix other applications/protocols!
If these need to use OpenPGP messages and they don't support binary
formats (which by itself is fine), then their own native means for
converting blobs into a suitable form should be used (e.g. XML's or
whichever) and if no such form exist, we should at best give a
recommendation about what to use (in the sense of referring to something
Especially I don't like the idea that applications out there may use the
ascii armor's enclosing (i.e. the ---- PGP ... ----) to detect "this is
a PGP message".
There should be other things around in the protocol that uses OpenPGP
which specifies that (e.g. Content-Type: headers).
I think it would be theoretically fine if a future OpenPGP standard
specifies multiple native formats, e.g. a binary one as we have right
now, a XML representation and whatever other ugly things (JSON?! ;-) )
people might want... but the ASCII armor isn't a real native format but
just an encoding, and that shouldn't be OpenPGPs duty.
 In practise, though, there should be really strong reasons if more
than one such native format would be defined.
Description: S/MIME cryptographic signature
openpgp mailing list