[OTR-users] [otr-users] Communication with Pidgin to Miranda (or others) has encoding problemes

[Paul Aurich]

And Rüdiger Kuhlmann spake on 02/23/2009 12:26 PM, saying:
> That may be true, but the README[1] specifically says that the text to be
> encrypted is what ever format the protocol specified (there is no "convert
> to XMPP-IM format" or anything like that),

Could you point out where the README says that? I can't seem to find it.

> and since XMPP quite clearly
> specifies that the body part contains plain text in UTF-8 (and not any HTML
> markup), the text (that is then encrypted) put into the body tag may not
> contain markup.
> 
> The comment from [2] is misleading, as of couse for protocols that define
> the text to contain markup, the decrypted text can contain markup. It's
> just that XMPP isn't one of them.

The OTR specification to me, seems to be effectively protocol-agnostic
(except with regard to maximum message size and fragmentation), which is
unfortunate in this case, because it does not really address this (at
least, from my quick once-over) and states that the unencrypted text
(without qualification for "only some protocols") is "encoded in UTF-8,
optionally with HTML markup."

> As such, the libpurple implementation is wrong, while Miranda and climm
> are correct.

Then shouldn't Miranda and cliMM either be complaining vociferously that
they received an invalid XMPP stanza or displaying the markup (i.e., the
message from gdb in my previous message would appear as
"foobarzle<br><br>foobarzle" in Miranda/cliMM, not
"foobarzle<br><br>foobarzle")?

> I remember that it was considered to change the lib to provide functions
> to encode markup and non-markup in the next release, but I have no idea
> what happened to it.

That sounds good. Will it allow for a single IM to contain two encrypted
payloads (one XHTML-IM, one plaintext)? I like the ability to send
marked-up text over OTR over XMPP.

Also, I'll repeat again: I'm of the opinion the libpurple OTR plugin's
current behavior is *wrong* from a "how should this protocol work in an
ideal world" perspective and unfairly relies on the receiver's client to
grok the markup and/or strip it, but to the best of my knowledge, that
isn't actually wrong according to the (underspecified, perhaps) OTR
specification, which says nothing about the unencrypted message needing to
conform to the rules of the protocol.

~Paul