Actually there is a separate plugin available for Miranda (same author as the OTR plugin - i.e. me) that will strip HTML from incoming messages - this is to allow for OTR interoperability with those clients that do work differently.<br>
<br>I had a similar discussion with the OTR authors about this as well, when I first implemented my plugin. I was never given useless links - they explained their position quite clearly. However I didn't and still don't agree. To them, OTR is a protocol in it's own right, existing on top of other IM protocols but having it's own rules. In the OTR spec it does say that messages belonging to the OTR protocol may contain HTML. I would much rather OTR be considered an extension to existing protocols, and have the unencrypted messages follow the rules of the underlying protocol. One motivation for this interpretation, I think, is that it may be more difficult to achieve this in the pidgin architecture (i.e. the message to be sent comes with HTML from the message window, goes via otr and then to the protocol for sending - usually the proto will decide if it can send the HTML but if OTR has encrypted the message that's not possible). With Miranda that problem is easily solved, but other things are harder (i.e. sending an 'i'm going offline now' message). <br>
<br>I don't think there's anything confusing to it - just a difference in philosophy. My concern is that the decision to call OTR a 'protocol' is motivated by convenience.<br><br>Scott<br><br><div class="gmail_quote">
On Mon, May 12, 2008 at 2:30 AM, Rüdiger Kuhlmann <<a href="mailto:l-otr.0705%2B23jv-l@ruediger-kuhlmann.de">l-otr.0705+23jv-l@ruediger-kuhlmann.de</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
>--[Jonathan Schleifer]--<<a href="mailto:js-otrim@webkeks.org">js-otrim@webkeks.org</a>><br>
</div><div><div></div><div class="Wj3C7c">> Rüdiger Kuhlmann <<a href="mailto:l-otr.0705%2B23jv-l@ruediger-kuhlmann.de">l-otr.0705+23jv-l@ruediger-kuhlmann.de</a>> wrote:<br>
> > As such, the place<br>
> > for text/plain is supposed to contain encryped text/plain, while<br>
> > the place for text/html is supposed to contain encrypted text/html.<br>
> That's exactly what I thought would be the right way to do it, thanks.<br>
> The problem is that Pidgin puts the HTML inside the XMPP *body*, which<br>
> is wrong, wrong and once again very wrong! It should put plaintext<br>
> there! It *may* use XHTML in the namespace reserved for it, but even if<br>
> it does so, it MUST also send a plain text variant, otherwise it<br>
> violates the RFC and the XHTML XEP!<br>
<br>
</div></div>The excuse that will pop up on the list will be:<br>
<br>
| But the encrypted text _is_ plain text and not HTML<br>
| and thus doesn't violate the XMPP RfC!!!111oneeleven!!!<br>
<br>
... which is technically true, but totally misses the point why<br>
this is wrong. The only thing ever said about integration says<br>
(from the README distributed with the libOTR source code):<br>
<br>
| If newmessage gets set by the call to something non-NULL, then you<br>
| should replace your message with the contents of newmessage, and<br>
| send that instead.<br>
<br>
So it says the only change to the data sent out is that the actual<br>
message is replaced by the encrypted one. In particular, it doesn't<br>
say to put the encrypted HTML in place of the text/plain part of<br>
the message, nor does it say anything about having to support HTML<br>
somewhere. I'm still waiting for someone to even try to bring any<br>
argument refusing my conclusion.<br>
<div><div></div><div class="Wj3C7c"><br>
Yours, Rüdiger.<br>
<br>
--<br>
"See, free nations are peaceful nations. Free nations don't attack<br>
 each other. Free nations don't develop weapons of mass destruction."<br>
      - George W. Bush, Milwaukee, Wis., Oct. 3, 2003<br>
</div></div><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.6 (GNU/Linux)<br>
<br>
iD8DBQFIJx8tHFs/RFyJr1ERAhmRAKCwwvcvdfugwWtkg5I4wdT70slFTACeLjoE<br>
21qA5lcAfn3svKS3p+rf41w=<br>
=MdDE<br>
-----END PGP SIGNATURE-----<br>
<br></blockquote></div><br>