>Okay I reread the RFC yet again :-) Literal Data packets of type text/unicode ('t' and 'u') have CR/LF EOLs not the ORIGINAL
>as I thought so I surrender and will change to just LF. I will submit another PR to fix master and change my pending PR for devel.

Of course you should not surrender ;-) Great to see the devel branch is making progress.
Where to do this change to LF? Just in Message.getText and CleartextMessage.getText?

>However in looking at the implementation of literalDataPacket and its usage I believe there are issues with incorrect encoding
>and decoding of UTF-8. I don't believe the current implementation will correctly handle encryption and decryption of binary data.
>I will submit a PR for review that cleans up the encoding / decoding issues.

I agree the literalDataPacket is somehow broken. If you call setBytes with UTF you decode, only to encode again when calling
getBytes? On the other hand 'text' could be also UTF8 but is not decoded there, the same for 'binary' this could be also UTF8.
We could move the decoding for example also to the Message.getText and CleartextMessage.getText methods maybe.