No subject

<br>

	<div class="smallfont" style="margin-bottom: 2px;">"Quote:</div>
	
	
		
I had a lengthy email conversation with Ian Goldberg, one of the
authors of OTR, libotr and the gaim-otr plugin. If you read the OTR
spec carefully, you will see that it specifies optional HTML-formating
in the plaintext. As OTR-messages are merely encapsulated using Jabber
(or other) protocols, Ian thinks (as do I after thinking about it) that
the OTR specs supersede the standards of "lower level" protocols such
as XMPP. It is the job of an OTR plugin to process the HTML tags in the
plaintext, if they are not used by the client it's the plugins job to
strip them.<br>
If you don't see it that way, I suggest you contact the otr-dev mailinglist."<br><br>I think of it quite the opposite way - OTR simply encapsulates protocol messages<br><br>OTR would have quite a job to do trying to detect whether the client supports HTML in Miranda - there are so many messaging modules etc. And they're likely to change at any time - it would make maintainence difficult. I don't think tracking the client's capabilities is the plugin's job.
<br><br>And I think the client should output the same *intended message* whether or not OTR is installed - after decription, OTR messages from gaim OTR contain formatting html, whereas without OTR gaim outputs no formatting html.  This means transmitting more information than usual - which, although very unlikely, may not be something that the user wants.
<br><br>Removing the tags means I would have to reimlement something already implemented by at least the AIM protocol plugin. Processing the codes 'properly' for the client could involve conversion from e.g. html to bbcodes, if the client supports those - which would mean differences in the nature of OTR plugins for different clients. Or further, if the OTR spec specifies handling of HTML, then the otr library should be able to handle it - but again that's a reimplementation of stuff that the protocol can already do.
<br><br>Also - and I really don't mean to criticize - but the protocol specs for things like jabber and other open protocols, with their RFC's and comittees etc etc, tend to be thought out pretty well. The reasons for disallowing things like 'mixed contect' (from the jabber RFC) are usually pretty good. For example, if I want to send the text <font>blue</font> to a friend, I can do so over jabber (because it is encoded and decoded by the protocol so as to not create 'mixed content') and expect him to get the message as I typed it, if the client performs to the spec. With OTR, if it's removing tags on clients that do not support markup, how does it tell the difference between formatting tags and what the user has typed? At a minimum it would somehow have to encode tags in message text and formatting tags differently - or you have restricted what messages users can and can't send.
<br>

------=_Part_201152_33376833.1174578923153--