I've spoken about this at length a long while back.<div><br></div><div>At present there is another plugin for miranda called 'NoHtml' to help with the problem.<br><br><div class="gmail_quote">2009/2/24 Paul Aurich <span dir="ltr"><<a href="mailto:paul@aurich.com">paul@aurich.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">And Rüdiger Kuhlmann spake on 02/23/2009 12:26 PM, saying:<br>
<div class="Ih2E3d">> That may be true, but the README[1] specifically says that the text to be<br>
> encrypted is what ever format the protocol specified (there is no "convert<br>
> to XMPP-IM format" or anything like that),<br>
<br>
</div>Could you point out where the README says that? I can't seem to find it.<br>
<div class="Ih2E3d"><br>
> and since XMPP quite clearly<br>
> specifies that the body part contains plain text in UTF-8 (and not any HTML<br>
> markup), the text (that is then encrypted) put into the body tag may not<br>
> contain markup.<br>
><br>
> The comment from [2] is misleading, as of couse for protocols that define<br>
> the text to contain markup, the decrypted text can contain markup. It's<br>
> just that XMPP isn't one of them.<br>
<br>
</div>The OTR specification to me, seems to be effectively protocol-agnostic<br>
(except with regard to maximum message size and fragmentation), which is<br>
unfortunate in this case, because it does not really address this (at<br>
least, from my quick once-over) and states that the unencrypted text<br>
(without qualification for "only some protocols") is "encoded in UTF-8,<br>
optionally with HTML markup."<br>
<div class="Ih2E3d"><br>
> As such, the libpurple implementation is wrong, while Miranda and climm<br>
> are correct.<br>
<br>
</div>Then shouldn't Miranda and cliMM either be complaining vociferously that<br>
they received an invalid XMPP stanza or displaying the markup (i.e., the<br>
message from gdb in my previous message would appear as<br>
"foobarzle<br><br>foobarzle" in Miranda/cliMM, not<br>
"foobarzle<br><br>foobarzle")?<br>
<div class="Ih2E3d"><br>
> I remember that it was considered to change the lib to provide functions<br>
> to encode markup and non-markup in the next release, but I have no idea<br>
> what happened to it.<br>
<br>
</div>That sounds good. Will it allow for a single IM to contain two encrypted<br>
payloads (one XHTML-IM, one plaintext)? I like the ability to send<br>
marked-up text over OTR over XMPP.<br>
<br>
Also, I'll repeat again: I'm of the opinion the libpurple OTR plugin's<br>
current behavior is *wrong* from a "how should this protocol work in an<br>
ideal world" perspective and unfairly relies on the receiver's client to<br>
grok the markup and/or strip it, but to the best of my knowledge, that<br>
isn't actually wrong according to the (underspecified, perhaps) OTR<br>
specification, which says nothing about the unencrypted message needing to<br>
conform to the rules of the protocol.<br>
<font color="#888888"><br>
~Paul<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
OTR-users mailing list<br>
<a href="mailto:OTR-users@lists.cypherpunks.ca">OTR-users@lists.cypherpunks.ca</a><br>
<a href="http://lists.cypherpunks.ca/mailman/listinfo/otr-users" target="_blank">http://lists.cypherpunks.ca/mailman/listinfo/otr-users</a><br>
</div></div></blockquote></div><br></div>