[otr-users] Pidgin plugin sends and parses HTML

[Scott Ellis]

>
> Uhm. I can only find one place where it mentiones HTML at all. And while
> it
> mentions that it may contain markup, it still doesn't qualify as allowing
> to
> put HTML into a place where only text/plain is allowed. Of course the text
> to encrypt may contain HTML, if an HTML message is about to be sent. Just
> as
> it may contain rtf, M$ .doc or any other markup if that is what is to be
> sent. But the data type of the data to be encrypted can only be determined
> by the underlying protocol, otherwise an extensive chapter on integration
> would HAVE to be part of the spec. It isn't.


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 *meaning* 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.

It claims that using libOTR is
> as simple as replacing the plain text with the output of the function.


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.

Can I suggest this discussion continue on the dev mailing list though?

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20080513/83ddfd18/attachment.html>