<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Uhm. I can only find one place where it mentiones HTML at all. And while it<br>

mentions that it may contain markup, it still doesn't qualify as allowing to<br>
put HTML into a place where only text/plain is allowed. Of course the text<br>
to encrypt may contain HTML, if an HTML message is about to be sent. Just as<br>
it may contain rtf, M$ .doc or any other markup if that is what is to be<br>
sent. But the data type of the data to be encrypted can only be determined<br>
by the underlying protocol, otherwise an extensive chapter on integration<br>
would HAVE to be part of the spec. It isn't.</blockquote><div> </div><div>The actual text transferred over the underlying
protocol is made up of plaintext chars - and as such none of the rules
of the underlying protocol are being broken. Even jabber XEPs cannot lay claim to the <i>meaning</i> of plaintext within messages - just as you and a friend are not prevented from using some code language you make up yourselves over jabber. Under this interpretation the
unencrpyted messages of OTR conversations have nothing to do with the
transport protocol. The phrase that was used by the developers in my earlier conversations on this topic was 'higher level protocol'. It's ugly and inconvenient to most of us, but it
does make sense from a certain point of view.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> It claims that using libOTR is<br>

as simple as replacing the plain text with the output of the function.</blockquote><div> </div><div>You're very right there - in most cases it doesn't perform 'as advertised'. But it does work that way for a lot of clients - almost anything Qt or Java based, for example.<br>
</div></div><br>Can I suggest this discussion continue on the dev mailing list though?<br><br>Scott<br>