[otr-users] Pidgin plugin sends and parses HTML

[Scott Ellis]

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.

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).

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.

Scott

On Mon, May 12, 2008 at 2:30 AM, Rüdiger Kuhlmann <
l-otr.0705+23jv-l at ruediger-kuhlmann.de<l-otr.0705%2B23jv-l at ruediger-kuhlmann.de>>
wrote:

>
> >--[Jonathan Schleifer]--<js-otrim at webkeks.org>
> > Rüdiger Kuhlmann <l-otr.0705+23jv-l at ruediger-kuhlmann.de<l-otr.0705%2B23jv-l at ruediger-kuhlmann.de>>
> wrote:
> > > As such, the place
> > > for text/plain is supposed to contain encryped text/plain, while
> > > the place for text/html is supposed to contain encrypted text/html.
> > That's exactly what I thought would be the right way to do it, thanks.
> > The problem is that Pidgin puts the HTML inside the XMPP *body*, which
> > is wrong, wrong and once again very wrong! It should put plaintext
> > there! It *may* use XHTML in the namespace reserved for it, but even if
> > it does so, it MUST also send a plain text variant, otherwise it
> > violates the RFC and the XHTML XEP!
>
> The excuse that will pop up on the list will be:
>
> | But the encrypted text _is_ plain text and not HTML
> | and thus doesn't violate the XMPP RfC!!!111oneeleven!!!
>
> ... which is technically true, but totally misses the point why
> this is wrong. The only thing ever said about integration says
> (from the README distributed with the libOTR source code):
>
> | If newmessage gets set by the call to something non-NULL, then you
> | should replace your message with the contents of newmessage, and
> | send that instead.
>
> So it says the only change to the data sent out is that the actual
> message is replaced by the encrypted one. In particular, it doesn't
> say to put the encrypted HTML in place of the text/plain part of
> the message, nor does it say anything about having to support HTML
> somewhere. I'm still waiting for someone to even try to bring any
> argument refusing my conclusion.
>
> Yours, Rüdiger.
>
> --
> "See, free nations are peaceful nations. Free nations don't attack
>  each other. Free nations don't develop weapons of mass destruction."
>      - George W. Bush, Milwaukee, Wis., Oct. 3, 2003
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIJx8tHFs/RFyJr1ERAhmRAKCwwvcvdfugwWtkg5I4wdT70slFTACeLjoE
> 21qA5lcAfn3svKS3p+rf41w=
> =MdDE
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20080512/0b68a3d0/attachment.html>